I would suggest using a single Request entity with a RequestType enum for different request types. You can consider using generalization only for the few types which may really need extra fields/behavior. Too many specialization will reduce your reusability in the microflows, pages also impact negatively on the DB retrievals (too many joins).

With regards to the workflow, I would suggest not to invent the wheel by yourself and use Mendix's own workflow module which may fullfill your expectations and I assume there might be solutions for whatever concerns you may have. This supports the lowcode philosophy also you may have more chance to focus on the business logic. Lastly some years later it will be easier for you or some other developer to modify the code when you use a standard module that may have many examples & documentations available.

Hi Tolga,

I prepared a draft domain model for my application (see Attachment 1). Please ignore the attributes and associations for now—this is just a rough version I put together in an hour to provide a general overview.

My idea is to keep common attributes in the Request entity. Using RequestType and RequestField entities, I want Application Admins to be able to define new attributes for any request type they need. This way, the application wouldn’t require redeployment whenever a new request type is wanted to be added. Do you think this approach is reasonable, or could it make the development/maintenance process unnecessarily complex in the long run?

Another point I’m considering is the workflow setup. Since I want to move forward with a single entity (Request for now), I’m unsure whether it’s better to use a single workflow across all requests or create a workflow per request type. Because, currently, the system design assumes the same workflow for all requests, but if new request types come in which require another flow, I might need another workflow. Would love to hear your perspective on these trade-offs.

Thanks,

Alp.

(Attachment 1)

(Attachment 2)