Skip to main content
A
ahmadb803565
May 13, 2025
Question

Best Practice for Managing Multi-Product, Multi-Process Data Models in BPM Platform

  • May 13, 2025
  • 8 replies
  • 0 views

Hello Community,

We are building an enterprise-grade BPM platform using Appian to manage various distributed banking processes such as loan applications, KYC, onboarding, and more. One of our architectural goals is to ensure flexibility and scalability, especially when dealing with multiple business domains and product types (e.g., Car Loan, House Loan, Personal Finance).

In our design, we have a universal process registry (PROCESS_MASTER) that links to all BPM activities. However, each product and process can introduce different sets of business-specific fields. We want to allow for product/process-specific data entry without creating a separate CDT or database table per product.

Proposed Approach:

  • Store shared/common fields in a structured APPLICATION_DATA table.
  • Store product-specific or process-specific fields using a DYNAMIC_ATTRIBUTES table (key-value structure) linked by master key.
  • Use Appian expressions and record interfaces to dynamically render fields based on metadata.
  • Use reference/config tables to define field types, validations, and UI grouping dynamically.

Questions:

  1. Is this DYNAMIC_ATTRIBUTES pattern (flexible key-value storage per case) recommended for scalable Appian implementations?
  2. Are there official Appian-supported patterns or accelerators that follow this model?
  3. How would you handle validation and type enforcement in such a dynamic model?
  4. Are there known performance or reporting limitations when using dictionary-based attributes and dynamic UIs?
  5. Would Appian Records and Process Reports still work effectively with this flexible model?

We want to future-proof our platform without over-customizing for each new product.

Any feedback or real-world experience would be much appreciated!

Thanks,
Ahmad Baghdadi
Solution Architect (Banking BPM)

8 replies

stefanhelzle0001
stefanhelzle0001
May 13, 2025
We are building an enterprise-grade BPM platform using Appian

But, isn't Appian already this enterprise BPM platform? In my 15 years doing Appian projects, I learned that trying to build something like this on top of Appian is not a good idea. Appian as a BPM platform is not meant to support using it to build such dynamic things.

I am currently working on a comparable project, and after long and hard discussions, we defined that we only want to make our "platform" to cover 70-80 percent of the very well known and simple uses cases just by configuration. For everything else, we make use of the low-code power of Appian to build whatever is required.

Just me 50 cents ...

A
ahmadb803565Author
May 13, 2025

Thanks a lot for the input — really valuable.

Just to clarify, our intent isn’t to rebuild BPM inside Appian, but rather to handle scenarios where most of the application initialization data comes from external systems (like CRM), including dynamic product-specific fields.

We're storing common fields in structured CDTs and using a DYNAMIC_ATTRIBUTES model only for optional or product-specific fields — mainly for display in back-office forms.

We’ll absolutely use Appian’s low-code strengths for more complex flows, but for the high-volume standard cases, this pattern helps us reduce friction and avoid schema changes.

Would appreciate your view on how you’d recommend handling this kind of external, product-variable data intake in Appian.

stefanhelzle0001
stefanhelzle0001
May 13, 2025

OK. Did you consider to just store a JSON string for that additional data? You could add a separate database like a MongoDB to store such dynamic things. The only "problem" would be that this is not compatible with synced records. This may, or may not, be an issue for you.

And then, did you consider to just leave the data where it is, and query it as needed?

In general, as Appian heavy relies on a relational database paradigm, storing dynamic data is always a bit awkward.

mathieud0001
mathieud0001
May 13, 2025

1. As a general rule, I would say no.

2. I don't know of any.

3. I would use config maps to store field configs/groupings. I would not store in the database.

4. Nothing particular but reporting becomes a bit of pain if you decide to go with #1.

5. It will work but Appian is not optimized for key/value data storage.

This doesn't mean that you can't use this type of design but there is nothing in Appian that is specifically optimized for it and like anything there are trade offs and compromises that need to be made. It depends on what your priorities are.

A
ahmadb803565Author
May 13, 2025

 So, do you recommend creating a structured record type for each application or process type and developing its own interface while adhering to the same UI standards using the SAIL UI interface?

mathieud0001
mathieud0001
May 13, 2025

It obviously depends on your requirements but in general, that is what I would recommend.

Terms & ConditionsAccessibility statement