“Validate assignment group membership” BR fails in domain-separated MSP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
45m ago
After the Brazil upgrade, a new out-of-box Business Rule named “Validate assignment group membership” was identified.
The rule has the following configuration:
- Table: sn_customerservice_case
- Execution: Before insert and update
- Scope: Case Management Core
- Created: March 27, 2026
The rule queries sys_user_grmember using a standard GlideRecord.query(). If it cannot find a matching membership record for the selected user and assignment group, it calls setAbortAction(true) and prevents the case from being saved.
In a domain-separated MSP scenario, cases may be created in a customer domain while the assigned user and assignment group are located in a provider domain.
A Flow Designer flow, configured to Run as System, creates the case in the customer domain and populates both assigned_to and assignment_group. However, during the flow execution, the provider-domain sys_user and sys_user_group records are not visible in the session.
As a result, the membership query returns no records, and the Business Rule aborts the case insert even though the assigned user is a valid member of the assignment group.
Questions
Which release introduced the “Validate assignment group membership” Business Rule, and what is its intended purpose? Is there a KB article, release note, known-error article, or product story describing it?
Is this Business Rule expected to support domain-separated instances? Is its behavior in an MSP cross-domain assignment scenario a known limitation or defect?
What is the recommended approach when the case is in a customer domain but the assigned user and assignment group are in a provider domain?
- Is there a supported system property or configuration setting?
- Should the OOTB rule be customized or overridden?
Is it supported to deactivate the OOTB Business Rule and replace it with a modified copy that handles domain-separated membership validation? If so, how would this customization be treated during future upgrades?
Evidence: debug log from the rule during flow execution shows runas: system, session domain equal to the case’s domain, userVisible: false, groupVisible: false, query(): false.
