Service Modules > Scheduling and Optimization > Service Board > Service Board for Implementers > Post-Sync Configuration Tasks > Working With Security Groups > Defining Security Group Rules
 
Defining Security Group Rules
After you define a target security group object, you next configure one or more Security Group Rules (SGRs). SGR records define the Data Access Rules (DARs) to be automatically generated to grant record-level access to security group members. When you define an SGR for a security group object, such as Service Team, one DAR record is automatically generated for each Service Team record, so that group members can see only records of the rule object, such as SVMX Job, that are related to that specific team. The following procedure shows an example of how to configure an SGR for the Job and Service Team objects.
* 
DAR records are not generated for records of the target security group object that have no related users linked through the Membership relationship, such as Service Teams that have no members.
To define Security Group Rules:
1. In Max Designer, on the Developer Tools () launchpad menu, click Object Designer, and then in the left pane, search for and select the Security Group Rule object.
2. In the left pane, click Records, and then in the list view, in the top left corner, click Create ().
3. On the record page, complete the fields as follows, and then in the top left corner, click Save and Close ().
Field
Value
Name
The name you want to use for the security group rule, for example, Access Jobs By Service Team Records.
Security Group Object
The object you want to use to generate security groups, for example, Service Team.
Rule Object
The object to which you want to restrict access by automatically generating data access rules, for example, SVMX Job.
LHS of Filter Expression
The left-hand side of the filtering expression to be created in the DAR. In general, this is the full identifier of the field that points to records of the object specified in the Security Group Object field. For example, the full identifier for the Relationship field that links the SVMX Job object to Service Team records is io_related_svmx_team.
* 
You can eager-load filtering expressions to access to records of an object that lack a field that points to the Security Group Object, but that have a related object that has a relationship to records of the relevant object type. For example, to restrict access to Job records that have no relationship to the Service Team object but do have a relationship to the Crew object. you can specify svmx_crew.io_related_smvx_team, where svmx_crew is the full identifier of the field in the SMVX Jobs object that points to Crew records, and the Crew object has a field with the full identifier io_related_svmx_team that points to Service Team records.
* 
For DAR restriction behavior to function properly, users should have roles with permissions that grant read access to all ServiceMax Jobs.
For more information:
Was this helpful?