Manual group additions are removed by a group rule after a merger
A 3,000-user company acquires a 240-person sales team. Salesforce access is granted through the Okta group CRM Users. That group is populated by a group rule: department equals Sales OR title contains Account Executive. The acquired users have department Revenue and title Account Exec. A well-meaning admin manually adds all 240 users to CRM Users. The next morning, 180 of them are gone from the group and cannot access Salesforce. Okta provisioning is enabled for Salesforce and is set to deactivate users when they are unassigned. The admin also notices 60 duplicate Salesforce accounts with the acquired company's old domain. The group rule has not been changed since the acquisition, and the Salesforce connector is licensed for 1,100 seats.
1. Why were the 180 users removed from the group even though the admin added them manually?
Read the worked answer
The group is managed by a group rule, so the rule owns membership. When the rule evaluates users, it adds those who match and removes those who do not. The acquired users have department Revenue and title Account Exec, which do not satisfy department equals Sales or title contains Account Executive. Manual additions to a rule-managed group are therefore unstable: the next evaluation can remove them. The 60 users who remained may have matched through another attribute, or the rule may not have evaluated all users yet. The lesson is to treat rule-managed groups as derived data. If a population needs access, either change the rule to match the real attribute values or use a separate manually managed group and do not mix the two models.
2. What changes would you make to the rule and provisioning configuration to restore access safely, and in what order?
Read the worked answer
First, confirm the acquired users' actual profile values and decide whether Revenue and Account Exec are the correct long-term values. Then update the group rule to include those values, preview the rule, and apply it. Wait for membership to populate and verify that Salesforce provisioning assigns the users rather than creating duplicates. Do not manually re-add users to the rule-managed group. Before changing the rule, review the Salesforce deprovisioning setting because a misfire could deactivate accounts. If possible, temporarily pause deprovisioning or test in a sandbox. After access is stable, reconcile the 60 duplicate Salesforce accounts by matching on a unique attribute such as email or employee ID, and confirm the 1,100-seat limit. The order matters: fix the rule first, validate provisioning, then clean up duplicates.
3. What is the risk of the Salesforce deprovisioning setting, and how would you validate it before the next merger?
Read the worked answer
The risk is that a group-rule error or an attribute change removes a user from CRM Users, which unassigns the Salesforce account, and the connector immediately deactivates it. That can lock out active sellers during a merger when profile data is messy. To validate it, I would test the rule and provisioning flow in a sandbox with representative users, confirm the deactivation behavior, and add a grace period or approval step before deactivation. I would also monitor provisioning events and group-rule changes, and run an access review before cutover. For the next merger, the identity team should map acquired attributes before enabling the rule, preview membership counts, and avoid manual additions to rule-managed groups. The judgement is to treat deprovisioning as a destructive action that needs guardrails.