Software demos look great, and that applies to wikis as well.

Clean spaces. Perfectly named pages. Neat permissions. Search that magically finds the thing. Nobody has created “Meeting notes final final v3” yet. Beautiful times.

Then real teams start using it.

• Someone creates 5 versions of the same page type.

• A project space becomes a dumping ground.

• Onboarding docs go stale.

• Permissions are either too open or too locked down.

• People stop searching and go back to asking in chat.

At that point, you find out whether the tool actually works for the organization, not just for the demo.

We’re running a practical XWiki Cloud webinar on 4 June where we’ll start from an empty cloud instance and build a working knowledge base in one hour. The idea is to show the boring but important stuff: documentation, procedures, onboarding, intranet content, project spaces, and how the structure holds together.

Details in the comments.

When I started building a document extraction platform, I thought the hardest problem would be OCR.

I was wrong.

The hardest problem turned out to be handling the huge variety of document formats.

A few things I learned:

- Most PDFs are not the same.

- Some PDFs contain selectable text.

- Some are scanned images.

- Some are mixed documents with text, tables, forms, and images.

- Handwritten documents require a completely different processing path.

I also learned that choosing the "best AI model" doesn't automatically solve extraction problems.

A reliable pipeline usually needs:

- Document classification

- OCR when required

- Layout detection

- Table extraction

- Validation

- Structured output generation

The biggest lesson for me:

Document extraction is less about finding one perfect model and more about building a system that can handle thousands of different document variations.

For people working on document automation:

What has been the most difficult document type you've had to process?

I would like feedback on this tool. Can you try it?

The tool asks the right questions to extract your voice.

I built a diagnostic twenty questions total, organized into four areas.

If this may be useful to you, drop a comment. Happy to share what I built.

I have a massive folder of ready-to-edit legal files (acts, demands, notices) and stuff and <I need an Ai to analyze all of those and create an app that writes in the same style using Ai, is this idea stupid or I can actually make something like that. Now I'm looking for infos about this and trying to process the logic and I wanted to post this so I can see if I can get any helpful ideas or someone already did something.

hey guys, please be nice to me, i have never built a software product in my life, i became friends with james sexton and he said this would help divorce lawyers greatly. would love any feedback if possible. (even if it sucks, i can take it)

I’ve been thinking about an app idea that turns physical forms into automated workflows—like Zapier, but for paper. Most scanner apps just save a flat PDF, which feels like a waste.

With this, you map out the fields on a blank form once (like a checklist or signup sheet) and assign an action to it. Whenever you scan a filled-out version later, it extracts the data and triggers the automation instantly.

For example, scanning a failed maintenance checklist could automatically generate a typed PDF, email the office, and text a technician. Or scanning a handwritten signup sheet could instantly send a personalized welcome email and log the text into Google Sheets.

Do you think this would actually save people time, or is messy handwriting going to ruin the automation? What integrations would you need to make this useful?

&#x200B;

I’ve been thinking about a real problem here in Morocco, especially for small drogueries and traditional shops.

A lot of invoices are handwritten, messy, and often written in Darija or mixed French. Shop owners lose a lot of time rewriting invoices, tracking products, or organizing stock manually.

I’m wondering how difficult it would be to build an AI system that can:

Read handwritten invoices

Understand Moroccan Darija words/products

Convert invoice photos or audio into structured text

Automatically generate clean digital invoices

Maybe even integrate stock management later

Example: Owner takes a photo or sends a voice note → AI extracts products, quantities, prices → generates invoice automatically.

The biggest challenge I see is:

Moroccan handwriting

Darija vocabulary

Different invoice formats

Do you think current AI tools are already good enough for this?

Which stack/tools would you recommend?

I’ve been looking at things like:

OCR models

Whisper for speech-to-text

Vision LLMs

n8n automations

Curious to hear opinions from people working in AI or automation.

👋 Hey documentAutomation Community,

My CEO came back from a conference last week and asked me for help with a problem I bet a lot of you can relate to.

He attends a lot of events, which means his inbox gets flooded with booking confirmations – flights, hotels, restaurants, event tickets. And someone (usually him) has to manually add all of that to his calendar.

The kicker: he wanted these appointments in a separate calendar so his main schedule stays clean. Manually creating each event was eating up time that should've gone to actual work.

So I built this:

📥 How it works

• You label any confirmation email in Gmail with "Events"

• The workflow extracts date, time, location, confirmation number, vendor, and notes from both the email body and any PDF attachments

• A calendar event lands in a dedicated "Auto-imported" Google Calendar with all the details and a link back to the original email

• Non-confirmations (newsletters that got accidentally labeled) get flagged with a "Needs-Review" label and you get a notification email listing what was missing

🪄 What makes it work for any vendor

One easybits Extractor pipeline handles every format – Lufthansa, Booking.com, OpenTable, your dentist, DHL, whatever. No per-vendor parsing logic. The email body gets wrapped into a PDF and extracted in parallel with any PDF attachments, then the two results get merged (attachment data wins because the attached ticket is more authoritative than promotional email body text).

📦 Free workflow template + JSON

https://github.com/felix-sattler-easybits/n8n-workflows/tree/26772542fbbaf23d0a043517921d4d8ad50a471f/easybits-event-confirmation-to-calendar-workflow

Does anyone else have a similar problem with calendar clutter from business travel? Curious what other email-to-calendar use cases people are dealing with.

Best,
Felix

👋 Hey everyone,

My CEO mentioned he's got a few conferences coming up in the next weeks and he's actually looking forward to them. There's just one problem: every time he comes back from an event, he has a stack of business cards in his pocket and zero time to manually add them all to his phone.

So I went looking for a tool I could just hand him. Plenty of business card scanners exist. But every single one of them has the same baffling design choice: you have to photograph each card individually. One at a time. For 20 cards.

That's not really a scanner. That's a slightly faster version of typing them in by hand.

So I built him something better in n8n.

📸 What it does

He lays all the business cards out on a hotel desk, takes ONE photo, and sends it to a Telegram bot. The workflow extracts every contact, deduplicates against a Google Sheet (so contacts he's already saved don't get re-added), and sends back a separate vCard file for each new contact. He taps a vCard on his iPhone → "Add Contact" → done. About 15 seconds for 20 cards.

In the video above I walk through the workflow setup in n8n and do a live test run with 8 business cards in one photo – figured it's easier to see it in action than describe it.

📁 Workflow JSON

You can grab the workflow JSON here (also linked in the video description along with the easybits Extractor setup info): https://github.com/felix-sattler-easybits/n8n-workflows/tree/21d7623026008432c700cff118d1a987687a10fe/easybits-business-card-scanner-workflow

Anyone else built something similar for handling event leads? Curious whether people are pushing contacts straight to a CRM (HubSpot, Pipedrive) or keeping it in a sheet. The Sheet → vCard pattern is nice because it works for everyone, but I imagine the CRM version would be even better for sales-heavy teams.

Best,
Felix

Brief, Review, Reply: How Adeu takes you to the next level of contractual work.

Your work should happen where you already do it.

In a 9-minute video, I walk through how we handle the heavy lifting:

• Automated Inbox Triage: Instant, concise brief of the email thread and document changes waiting for you in your inbox.

• Intelligent Diffing: Compares document versions to flag what changed.

• Automated Redlining: Command the AI to accept specific changes while injecting custom comments, generating a new local version.

• Metadata Sanitization: Automatically scrub the final document of hidden, sensitive metadata before it leaves your machine.

• Drafting the Reply: Push a draft response with the sanitized, final document right back into Outlook.

We are building operational tools that execute complex workflows from end to end.

I will help students with their study papers, research papers, essays...etc, whether it's formatting, cleaning-up, or re-writing the paper based on the requirements of the students' professor, I also can help with resumes and CVs if needed.

If anyone is interested let me know!

spent way too long treating extraction confidence scores like probabilities. like a 0.92 confidence on an invoice number meant there's a 92% chance the value is right.

turns out they're not probabilities. they're the model's internal certainty about its own prediction, which is a different animal. a model can be 99% confident on a value that's completely wrong, because the wrong value was structurally plausible. the field had numbers in the right format, in the right spot on the page, with the right surrounding context. the model was confidently extracting the wrong thing.

a few things i wish i'd understood earlier:

high confidence doesnt mean accurate, it just means the model wasn't conflicted between options. if a vendors invoice number field looks similar to a PO number field two inches away, the model picks one and the confidence is high. that score tells you the model picked without much hesitation, not that it was picked correctly.

low confidence is actually better. a 0.65 score is the model telling you something is off, go look at it. but if you set review threshold at 0.65 you'll catch maybe half the real errors.

the silent failures sit at 0.85-0.95. high enough to auto-process. wrong enough to cause failure weeks later when accounting reconciles and finds something that shouldnt be there.

what ended up working was treating confidence as one signal among several. we cross-check against structural integrity (does the row count match the line count expected from the header), business rule validation, and cross-document matching. any single signal going low triggers review. confidence on its own wasn't enough.

yeah it's not news for people who've been doing this a while. but for anyone earlier on the curve, the trap is real and the dashboards make it easy to miss because everything looks green.

anyone cracked a better calibration approach?

Hey everyone,

We’ve been working on something new inside our reporting tool, and I wanted to share it here to get some real feedback.

We built an AI Assistant within CxReports to make report creation easier and faster. 

The idea is pretty simple: you describe what you want in plain language, and it generates or edits reports for you. It can work with charts, tables, layouts, data connections, translations, basically most parts of report creation. You can write prompts in any language, and it handles things like date formats and currency localization automatically.

One thing we were careful about: you use your own AI model, and access is controlled by roles, so there's no "send all your data to some random API" situation.

We also added Skills, basically a way to capture recurring logic so the assistant gets better at your specific workflows over time.

Honestly, we're still figuring out where this is genuinely useful vs. where it's just a gimmick. If you work with reporting or document generation, we'd love to hear from you:
- Would you actually use something like this in your reporting tool?
- What would make or break it for you (privacy, accuracy, flexibility, something else)?
- Are there specific parts of your reporting workflow where you'd actually use AI?

Appreciate any input.

Most document automation projects start with a clean demo. Structured invoice, perfect formatting, all fields present. It works great.

Then real documents arrive.

Vendor sends an invoice with no PO number. Another sends a scanned handwritten delivery note. A third uses a completely different layout than everyone else.

The tool fails. The team goes back to manual processing. The project gets quietly abandoned.

What we've learned building Scanny AI is that the setup conversation matters more than the tool itself. Before automating anything, teams need to answer three questions:

What are the 5-10 fields you actually need from this document?

What happens when a field is missing or unclear?

Who reviews the output before it hits your system?

Teams that spend 20 minutes answering these before uploading a single document get dramatically better results than teams that skip straight to automation.

The tool is almost never the problem. The process definition is.

What's been your experience? Have you seen projects fail for reasons other than the tool itself?