Hello,

Can you please specify how exactly do you want to put customers and accounts in a specified group?

Hey @malika, the plan is to create  a separate section in our database for the our accounts that need to be managed by this role

Edouard,

To achieve this setup—granting a user access to basic platform features while limiting visibility to only a specific group of customers—you can configure object permissions by system operations in Creatio.

Here’s a general outline of how you can do this:

Create a role for the user that includes access to the required basic features.

Use object operation permissions to restrict access to the “Account” and “Contact” objects.

Within those objects, configure record-level permissions so that the user role only has access to a defined group of customers/accounts.

You can achieve this by assigning access rights to specific records or groups (e.g., based on an attribute like owner, category, or tag).

You can follow the detailed steps in this article:
👉 Object permissions by system operations – Creatio Academy

Hope this helps! 

Hello Dharini,

Hope you're doing well.

It's not recommended to bind the access rights to the package. All system administration settings like object permissions, operation permissions, roles, users, distributed licenses must be set up in the production environment directly.



However, you may find this Creatio community post useful if you would like to try to transfer access rights using an SQL script in the package:

https://community.creatio.com/questions/how-can-we-bind-access-rights-data-section-dashboard-2

In your particular case the needed table like Sys[SectionFolder]Rights.

Best regards,

Roman

Roman Rak,

Hi Roman. Can you share why it is not 'recommended'?



We have heard different versions from different sources in Creatio. The take away for us has been that - It is 'feasible' to data bind access rights in a package but not 'recommended'. 

Hello Dharini,

At the moment, the mechanism for import/export of access rights, the structure of organizational/functional roles cannot be performed using the basic tools, as far as it complex for the architectural implementation. Our R&D team is currently working on its implementation and it will be available in future releases. 

About the question of why it is 'not recommended':

from a development point of view, this business task is complicated, since unique record IDs are created for each system, so that's why we do not recommend transferring access rights by development. And in case you decided to bind this data and transfer to another environment we suggest checking all changes on the copies before delivering it to the prod sites.

Best regards,

Roman

Roman Rak,

Thank you Roman. So it is more about skill than anything to do with the product.