---
sourceDocument: Australia Governance, Risk, and Compliance
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/governance-risk-compliance

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Governance, Risk, and Compliance

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# Group owner fields and role requirements

# Group owner fields and role requirements {#ariaid-title1}

Release version: Australia  
Updated November 5, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Group owner fields and role requirements

This document provides detailed guidance on group ownership functionality within the Business Continuity Management (BCM) suite in ServiceNow Australia release.
Group ownership applies to three BCM record types: Business Impact Analysis (BIA), Business Continuity Plan (Plan), and Recovery Event (Event).
Each record type uses specific field names for group and individual ownership but follows consistent logic for role-based filtering, mandatory validation, and access control.
Show full answer Show less  

## Field Mapping and Role-Based Filtering

Each BCM record type uses distinct field names for group and individual owners:

* **BIA:** Group field - BIA Owner group; Individual field - BIA Owner
* **Plan:** Group field - Plan owner group; Individual field - Plan owner
* **Event:** Group field - Assignment group; Individual field - Assigned to

The selectable groups for the owner fields are filtered based on role eligibility to ensure only qualified groups can be assigned ownership:

* **BIA:** Groups must have BIA Planner or BIA Manager roles.
* **Plan:** Groups must have Plan Owner or BCM Manager roles.
* **Event:** Groups must have task assignment permissions as defined by the sntask table role model.

## Individual Field Behavior and Validation

The individual owner field dynamically filters candidates based on the selected group and is pre-populated with the current user by default across all record types. A mandatory validation rule requires that at least one ownership field (group or individual) is populated before saving a record. Records with both fields empty trigger an error highlighting the fields and prompting the user to select a group or individual.

## Role Permissions and Access Control

Role-based filtering enforces proper permissions and separation of duties:

* **BIA Owners:** Must hold BIA Planner or BIA Manager roles to create, edit, and maintain BIA records.
* **Plan Owners:** Must hold Plan Owner or BCM Manager roles for Plan records management.
* **Event Assignment Groups:** Must have task assignment permissions aligned with the sntask role model to manage recovery event activities.

## Backward Compatibility and UI Consistency

Existing records with individual owners only continue to function without requiring the group field. Workflows referencing individual owner fields remain unaffected unless explicitly updated to use group ownership. Role-based group filtering operates at the reference qualifier level to exclude ineligible groups from selection. The feature supports flexibility by allowing selection of individuals outside the owning group for exceptional cases. Both Classic UI and Business Continuity Workspace offer consistent group ownership experiences.  
Reference guide for group owner role eligibility requirements, field mapping, and filtering logic across all Business Continuity Management record types.

## Group ownership functionality {#owner-group-eligibility-roles__overview}

Group ownership is available across three BCM record types: Business Impact Analysis (BIA), Business Continuity Plan (Plan), and Recovery Event (Event). Each record type maintains its own field naming convention while sharing the
same logic for filtering, mandatory validation, and role-based access control.

## Field mapping by record type {#owner-group-eligibility-roles__field_mapping_all_types}

The following table shows the field naming convention for each BCM record type:
{#owner-group-eligibility-roles__field_mapping_all_types__entry__4}

| Record Type | Table Name | Group Field Name | Individual Field Name |
|-|-|-|-|
| Business Impact Analysis (BIA) | sn_bcp_impact_analysis | BIA Owner group | BIA Owner |
| Business Continuity Plan (Plan) | sn_bcp_plan | Plan owner group | Plan owner |
| Recovery Event (Event) | sn_recovery_event | Assignment group | Assigned to |
[Table 1. Field mapping and definitions]

## Role-based group filtering {#owner-group-eligibility-roles__role_eligibility}

The group field on each record type filters candidate groups based on role eligibility. Only groups that hold a role equivalent to the record's owner role are shown as selectable options. This verifies that groups shown in the
owner field have the permissions needed to manage the record.
{#owner-group-eligibility-roles__role_eligibility__entry__4}

| Record Type | Groups Shown | Groups Excluded | Purpose |
|-|-|-|-|
| BIA records \[sn_bcp_impact_analysis\] | Only groups holding the BIA Planner role OR the BIA Manager role | Any group without one of these roles is not shown in the BIA Owner group selectable list | Ensures only qualified groups can be assigned as BIA record owners |
| Plan records \[sn_bcp_plan\] | Only groups holding the Plan Owner role OR equivalent BCM Manager role | Any group without one of these roles is not shown in the Plan owner group selectable list | Ensures only qualified groups can be assigned as Plan record owners |
| Event records \[sn_recovery_event\] | Only groups with task assignment permissions (inherited from sn_task table role model) | Any group without the required task assignment role is not shown in the Assignment group selectable list | Ensures only qualified groups can be assigned as Event record owners. Filter may vary based on task table configuration |
[Table 2. Role-based filtering by record type]

## Individual field filtering across record types {#owner-group-eligibility-roles__individual_field_filtering}

The individual field (BIA Owner, Plan owner, or Assigned to) adjusts its filtering behavior dynamically based on group selection across all record types.

## Record type comparison {#owner-group-eligibility-roles__record_type_comparison}

{#owner-group-eligibility-roles__record_type_comparison__entry__4}

| Aspect | BIA records | Plan records | Event records |
|-|-|-|-|
| Group field name | BIA Owner group | Plan owner group | Assignment group |
| Individual field name | BIA Owner | Plan owner | Assigned to |
| Eligible group roles | BIA Planner OR BIA Manager | Plan Owner OR BCM Manager | Task assignment role (from sn_task) |
| Default individual | Current user (pre-populated) | Current user (pre-populated) | Current user (pre-populated) |
| Default group | Empty | Empty | Empty |
| Classic UI section | User Administration | User Administration | Assignment details |
| Workspace section | Assignment details | Assignment details (Details tab) | Assignment details (Create Event page) |
[ ]

## Mandatory validation rules {#owner-group-eligibility-roles__validation_rules_all}

Group ownership implements a special mandatory validation rule across all three record types: at least one of the two fields (group or individual) must be populated.
{#owner-group-eligibility-roles__validation_rules_all__entry__2}

| Validation State | Behavior |
|-|-|
| Group populated, Individual empty | Valid --- record can be saved |
| Individual populated, Group empty | Valid --- record can be saved (legacy behavior) |
| Both populated | Valid --- record can be saved |
| Both empty | Invalid --- both fields highlighted in red with asterisk; mandatory error displayed; user must populate at least one field |
[Table 3. Validation states]

Error message on submit with both fields empty: Both fields are outlined in red with an asterisk indicator, and a validation error is displayed prompting the user to fill in either field.

Guidance banner: Select either a group or an individual to save the record and proceed with the workflow.

## Role permissions and access control {#owner-group-eligibility-roles__permissions_and_access}

Role-based group filtering ensures that only groups with the appropriate permissions are eligible to own records of each type. This approach maintains proper separation of duties and access control across the BCM suite.
{#owner-group-eligibility-roles__permissions_and_access__entry__2}

| Record Type | Required Permissions |
|-|-|
| BIA Owner permissions | Groups assigned as BIA Owner must hold either the BIA Planner role or BIA Manager role. These roles grant permission to create, edit, and maintain BIA records within their scope. |
| Plan Owner permissions | Groups assigned as Plan Owner must hold the Plan Owner role or an equivalent BCM Manager role. These roles grant permission to create, edit, and maintain Plan records within their scope. |
| Event Assignment permissions | Groups assigned as Assignment group must hold appropriate task assignment permissions (inherited from the \[sn_task\] table role model). These roles grant permission to manage and track recovery event activities. |
[Table 4. Role permissions by record type]

## Backward compatibility and legacy behavior {#owner-group-eligibility-roles__implementation_notes}

{#owner-group-eligibility-roles__implementation_notes__entry__2}

| Scenario | Behavior |
|-|-|
| Existing records with individual owner only | Continue to function unchanged. The group field is optional; no changes are required for records with only an individual owner. |
| Automation and workflows | Workflows that reference the individual owner field are unaffected by the group ownership feature unless explicitly using the group field. |
| Role-based group filtering | Enforced at the reference qualifier level, ensuring that ineligible groups are excluded from the selectable list before presentation to the user. |
| Outside group selection | The "Allow selection outside the group" informational message provides flexibility for edge cases. An individual may serve as owner even if not formally part of the owning group. |
| UI consistency | Both Classic UI and Business Continuity Workspace implement group ownership consistently, ensuring a unified user experience across UI platforms. |
[Table 5. Backward compatibility features]

* **[BIA owner field reference and validation rules](https://www.servicenow.com/docs/Z132KS3dPn7uhTck6De32w)**   
  Detailed field definitions, validation rules, filtering logic, and technical specifications for group ownership in Business Impact Analysis (BIA) records.

**Related concepts**   

* [Group ownership in BIA, plan, and event records](https://www.servicenow.com/docs/TXh~cF7PFqn~vtmQksVEqg "Assign a user group as the owner of business impact analysis (BIA), plans, and event records, instead of or alongside an individual owner. Every member of the owner group gets the same access to these records as an individual owner.")