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.
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 BaghdadiSolution Architect (Banking BPM)
Discussion posts and replies are publicly visible
ahmadb803565 said: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 ...
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.
DYNAMIC_ATTRIBUTES
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.
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.
We cannot use MongoDB since we are currently using Oracle Database. We prefer to stay within the Appian data fabric and its caching mechanism to avoid losing important record type features. Therefore, we are looking for the best solution for our needs. 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?
I would want to recommend going this way, yes.
Before Appian, we/you always wanted to build this highly flexible and generic frameworks. Developing took ages and we wanted to get the most out of it.
With Appian, development is fast and easy. So we can just build the things as they come up.
Said that, this is a whole different way of how to think about building software, and it has its very specific way to success.