Group rules best practices
Group rules are applied to your entire org, and they can be triggered whenever you change a user's profile, group membership, or lifecycle state. Observe these best practices when creating group rules:
- Review your existing rules to prevent duplicate conditions. Creating three separate rules with the same condition means that eligible users are members of three separate groups. Additional rules take longer to evaluate, and they can stretch your org's group limit.
- Eliminate cascading rules. Cascading rules cause performance issues because they refer to a group that is populated by another rule. For example, Rule 1 says If user.city == "San Francisco", then assign to group California. Rule 2 says if user isMemberOf(California), then assign to group West Coast. Solve this by creating a rule that says If user.city == "San Francisco", then assign user to California and West Coast.
- Preview your rules on a test user before you save it. Group rules are enforced immediately after they are activated. During rule setup, enter a test user's name in the Preview field. Verify that the user was evaluated correctly, and then save and activate your rule.
- Be aware of how your group rules affect app membership. Group rules can cause an application's membership to drop below your import safeguard settings. Import safeguards prevent user import jobs from unassigning too many members from an application. However, if a group rule lowers the app membership, or if an import job changes a property in a group rule, the safeguards will not be triggered. See Import safeguards.