Hello,
I am trying to set up record permissions for the Account object based on the record owner. In particular, the business developers of our company should see ONLY accounts they personally own, but not records of their peers. The manager role should retain all access.
However, there is only an option to "Grant permissions based on the record author" out of the box. Is an optimal solution to achieve the above using a business process?
Like
Hi Jakub,
You can handle this by enabling record permissions and automate the assignment of rights using a Business Process. This ensures permissions are accurate even when the record owner changes.
Step 1:Go to the Object Designer for the Account entity and enable the Records checkbox under the Access Rights section. This allows you to define permissions for individual records rather than the whole object.
Step 2: Within the Record permissions tab under the Object Permissions of the Account object, add a rule for the Manager organizational role. By granting them full access (Read, Edit, Delete) for records created by the "All Employees" role (or your specific author role). This ensures that managers retain complete visibility and control regardless of which individual user owns or created the record.
Step 3: Since the "Record Author" and "Record Owner" are not always the same, you can create a simple Business Process to handle dynamic access:
- Trigger: Set the process to run on the Addition of an Account and on the Modification of the Owner field.
- Logic: Use the "Change access rights" element to:
- Grant Access: Assign necessary permissions to the user currently in the Owner field.
Yes the best way to control additional access to records is via 'change access rights' action. A simple process could be when a record is added or owner field is modified a business process runs to grant the access you require. You have to have 'use record permissions' activated on the object.
Hello
Based on your description, this is a common and valid business requirement: business developers should only see the accounts they own, while managers need full visibility.
We reviewed this scenario and found that implementing it through a business process is not the recommended approach.
In the current implementation, data access in Creatio is managed through the access model, including object permissions, record permissions, and role hierarchy. Record-level access—such as limiting users to their own records—is intended to be configured declaratively, not handled through business processes. This ensures access control remains consistent and independent of runtime logic.
Regarding permissions based on the record author: this refers to the system field storing who created the record. In your case, access should be based on the record owner, which reflects responsibility rather than authorship. These are different concepts, and using the author field would not reflect ownership, especially if records are reassigned.
For this scenario, we recommend configuring record permissions on the Account object so that access is granted to the owner. This includes enabling record-level permissions, restricting broad access for business developers, and ensuring only the owner (and higher-level roles) can access each record. Managers can retain visibility through the role hierarchy, inheriting access from their subordinates.
A business process can assign permissions dynamically (e.g., on create or update), but this should only support the configuration. When permissions depend on process execution, they become harder to maintain and troubleshoot. From an architectural perspective, a configuration-driven approach is more reliable.
Additionally, if ownership changes, a process-based approach requires manual permission updates, while a properly configured access model handles this more consistently.
Hello, thank you for the exhaustive reply.
"We recommend configuring record permissions on the Account object so that access is granted to the owner..." That is exactly what would solve our situation but how can this be done? I expect a back-end development using C# would be needed?
Additionally, would the record permissions based on the access model propagate to related records? For example, if we configure permissions for Accounts this way, will they apply to the Account's Activities etc.?
Viktor Komarov,
Ok I did not know that was an option (to set the owner) and I cannot see that option within the object. Ideally this would be a better solution (for this scenario) but business process gives you a lot more flexibility in setting permissions based on other fields, such as record status within a workflow.
Hi Jakub,
this should follow the same logic as described in these scenarios asked before by other users:
Set up Record Permission Based On The Assignee Role | Community Creatio
Short answer: Creatio allows Record level permissions to be declared in the Configuration based on record authorship.
If you would like to extend this logic to be based other fields of a record, you need to create a Business Process that listens for a appropriate signal (e.g. record created, "Owner" column modified...) and then modify the Record Permissions according to your preferred business logic by using the "Change access rights" Element inside the Business Process.
Academy References:
- Manage access permissions with business processes | Creatio Academy
- Change access rights process element | Creatio Academy
Heads-up: If you require a permission update in bulk for large datasets/multiple Objects (e.g. after a reoccuring Data Import), the Record Permission Processes can take a while, so it might be better to perform such updates outside of core business hours.
Best,
David
Hello David,
thanks for confirmation and references. I have decided to go with the business process solution and so far it works as expected.
Best regards,
Jakub