For organizations using Custom Objects to model business flows, permission inheritance automation previously required you to set up Workflow Rules. You can now automate permission inheritance when working with Custom Objects to set or inherit permissions based on their related item.
- Quicker user access to data, from optimized system performance
- Remove administration overhead removing Workflow Rules
- Mirror system behavior of permission inheritance to Cases, to your custom objects
How it Works
There are 2 ways to create linkages between custom objects and other objects:
- Reference to Object from a custom object to a Work Item or Case
- Links between a custom object and other objects, for example, custom objects to standard objects or to other custom objects (learn more)
1. Reference to Object method ("one-to-many" an object has many attached custom objects)
In this setup, you have a field on a custom object (e.g. "Business Plan") and Projects.
You can reference the Project as a field from the custom "Business Plan" object.
Any Business Plans referencing the Project will inherit Edit and View permissions from the Project, meaning that the Project team will enjoy full visibility. In this case, permissions always flow from the Work Item (Program, Project, Milestone, Task) or Case (Issue, Risk, Request, Bug).
2. Link Method ("many-to-many")
In the Custom Object Link properties, you can enable permissions inheritance in one direction between the linked items, however, you can also inherit permissions to the standard objects and to other custom objects.
In this example, we have permissions that can be inherited by a custom Product object from a custom Vendor object.
- To avoid circular reference scenarios where permissions cannot be removed, you can only set permission inheritance in one direction.
- Continue to use workflow rules to automate permission inheritance if you want to selectively inherit, for example, to only take Viewers.