Account Properties - Microflow Returned Row Limits

0
Hi Everyone,   A bit of a hybrid question - I am developing an app where I need an account to have an attribute / property that can be modified as the business needs. The standard account entity does not have this attribute (which would have a 4 selection ENUM). Reading up on this my approach is to extend the Account entity and add the property I need to create a specific account / user type for our business. I have created this entity in one of my custom modules and am intending to apply it to the app level security role(s).   Further, some rows of data will need to be visible ONLY if the ENUM selected in the Account entity meets certain criteria - e.g. Salesperson OR Sales Manager. I've been told that a Microflow to feed a list would be a best approach for this.   So, my question is twofold. Am I heading in the right direction regarding extending the base account entity / object or is there a better way to approach this? If not, will I need to create custom entities for all my role types? Secondly, are there limits to the number of rows I can comfortably return in my Microflow to support this without creating performance bottlenecks.   This is a bit of an odd question, but I need to ensure I get security - particularly data access - right from the get-go for this app.   Thanks!
asked
4 answers
0

Hi David,

    Extending the Account entity and using an ENUM is the correct approach. However, avoid creating separate entities for roles. Instead, utilize the ENUM along with access rules. Additionally, optimize your microflows for better performance by implementing constraints and pagination.

 

Regards

Guna

answered
0

Extending the Account entity and adding the ENUM attribute is a good approach for customizing user types. Using a Microflow to filter rows based on the ENUM is also effective. For performance, ensure the Microflow handles only the necessary rows and test with your expected data volume to avoid bottlenecks.

answered
0

Hi together,

changing an Marketplace Module is NOT recommended. You have two options to extend your user entity with information. Check the Docs for more information.

  • Create a custom specialization of System.User
  • Create a 1 to 1 association

 

I don't know your use case exactly but it looks like a multi-user role approach would be a more efficient approach. Then you can change the visibility of the different componements based on role.

Per User Role in User management you can define who can change which role.

 

 

answered
0

Hi David Service,

                 Use a single ENUM attribute to distinguish between different role types.

                  Using one ENUM for different roles and managing specific attributes or access control based on that role is more efficient than creating separate entities for each user role

answered