Planning permissions
Tips and suggestions
If your organisation is new to Alloy, you can use the system groups to get started. By assigning users to these preconfigured permission groups, you can give them access to the features they need.
Over time, you can create and configure custom permission groups that are better suited to your organisation. Alloy's flexible permissions system lets you define multiple levels of access to specific objects within various data categories. You can even control access to individual attributes!
While every organisation is different, here are some general tips and suggestions to help you plan your permissions structure.
For bespoke advice on setting up permissions, have a chat with your Alloy representative 👩💼 👨💼
Create variations of the system groups
Alloy's system groups are fairly broad in scope. As your organisation develops its own designs and interfaces, you can create variations of these groups for each of your asset or activity types.
For example, the Defect Managers system group applies to all defects. Consider replacing it with groups like Bollard Defect Managers, Postbox Defect Managers, and so on.
Additionally, the system groups provide two levels of access: Viewers (read) and Managers (create, read, edit, delete). You can expand on these concepts by defining other access levels and creating groups for them.
For example, you could have Editor groups that let users read and edit items but not create or delete them.
Use an interface to target multiple designs
By setting permissions on an interface, you're setting them on all the designs that implement it. This makes it easy to set the same permissions across multiple related designs.
For example, for an Asset Viewers group, you could enable the Read permission on the Asset Heads interface, which is implemented by all asset designs.
If you set permissions on any of the interface's attributes, the designs will inherit them too. This means you can control access to inherited attributes independently from whatever permissions are set on the design.
For example, you want a group that can register defects against assets, even if they lack write access to those assets. To do this, set the Defects attribute of the Defects Assignable interface to "Read write".
For example, you don't want a group to see the Target Time of tasks, even if they otherwise have full access to those tasks. To do this, set the Target Time attribute of the Tasks Assignable interface to "None".
Inherited interface permissions can be overridden by permissions set directly on a design. However, inherited attribute permissions can't be overridden.
Ensure users can view Link attributes
Link attributes often store items of a different design. Therefore, when setting permissions on a design/interface, make sure the group also has read access to the relevant design of any Link attributes. Otherwise, users will receive an E1539905172 error whenever they view, create or edit items of the initial design/interface.
For example, the Defects interface has a Link attribute named Status that stores items of the Defect Statuses design. If you enable the Read permission for the Defects interface, do the same for the Defect Statuses design.
Some organisations like to create a single group (e.g. Lookup Viewers) that enables the Read permission on a custom interface (e.g. Lookup Designs) implemented by all their lookup designs (e.g. Material Types, Ground Conditions). This is a convenient way to ensure users don't experience errors when viewing items, though it may be unsuitable for some organisations.
Restrict access to job work items
You may want to grant access to jobs while restricting access to their constituent job work items. This is a common scenario for organisations that employ multiple contractors, as job work items can contain sensitive information like costs.
If a group has no access to the Job Work Items interface, its users will experience errors when viewing, creating or editing jobs. Besides, you probably do want them to see a job's work items, just not the sensitive bits!
The solution is to enable permissions as needed on the Job Work Items interface but set the None permission on some or all of its attributes, e.g. Estimated Rate Used, Actual Cost.
Alternatively, you can create custom job work item types (create a design that implements the Job Work Items interface). You can then govern access at the design level, so that only certain groups can see certain job work item types.
Keep things minimal
When defining a group's permissions, it's best practice to keep them as minimal as possible. Focus on a handful of data categories, only set permissions on objects that need them, and create separate groups when appropriate.
By keeping groups minimal, they can be readily combined with other groups across multiple roles. This makes user management easier, as users can be assigned to a couple of roles rather than dozens of groups.