RE: How Should We Handle Documents in Enterprise BPM with Appian + DMS?

ahmadb3492 — Mon, 14 Jul 2025 08:32:43 GMT

Hi Stefan, really appreciate your insight.

You're absolutely right blindly centralizing across applications can cause more harm than good if not well-scoped. And your point about finding the right level of generalization is spot on.

In our case, we’re building a single unified Appian BPM platform for a bank, not multiple siloed apps. This BPM layer handles many core processes (e.g., Loan Origination, KYC, Complaints, etc.), and receives structured data from CRM via Kafka. Each process involves different entity types (e.g., applicants, collaterals, companies), and each of those can require documents at different stages — including mid-process uploads triggered by Credit or Risk teams.

So our design centralizes only the document logging layer via a normalized DOCUMENT_LOG table

which stores:

process_id

entity_type (like APPLICANT or COLLATERAL)

entity_ref_id

document_type

Appian document ID and/or DMS UUID (we use an external DMS)

This avoids scattering document columns across business tables and gives us a clean, auditable document trail across processes.

We're not trying to build one centralized record or interface — just a decoupled way to log and track documents cleanly.

As for the vendor’s concern: they argued that Appian has a 3-level relationship limit and that this prevents them from saving nested structures with documents. But that seems more like a limitation of how they’re using a!writeRecords() rather than an actual Appian restriction. We’ve suggested saving the documents after saving the related entities (using the returned primary keys), which avoids the issue entirely.

So to summarize:

We agree that overgeneralization is risky

But in this case, document tracking is the exact kind of concern worth centralizing

The "3-level depth limit" seems more about tooling convenience than a real architectural blocker

Thanks again for your thoughtful reply. Would love to hear if others have used similar patterns — especially in enterprise Appian+DMS scenarios.

RE: How Should We Handle Documents in Enterprise BPM with Appian + DMS?

Stefan Helzle — Mon, 14 Jul 2025 05:57:35 GMT

In my experience, trying to centralize things across multiple Appian applications is a mixed bag. I have seen systems where colliding requirements and expectations lead to serious issues.

The real challenge is to find the right level to generalize certain functionality. There is no wrong or right as it always depends on so many things.

[quote userid="289791" url="~/discussions/f/best-practices/39436/how-should-we-handle-documents-in-enterprise-bpm-with-appian-dms"]

We believe a centralized and normalized DOCUMENT_LOG table is more scalable across processes and systems.

They say:
The vendor mentioned Appian has a 3-level relationship depth limit, which makes saving deeper/nested data and documents together challenging, especially in bulk operations.

[/quote]

I do not opt for centralized objects, and try to build a simple data model, even if that means it is only slightly normalized.

Then, I do not know of any hard limit in terms of relationship depth. But, I have seen deeply nested models to suffer in performance, when, and only when, queries become complex. But this is no different to a slow view in a database.