---
sourceDocument: Australia Strategic Portfolio Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/it-business-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Strategic Portfolio Management

ft:clusterId :

    - itbm

bundleId :

    - itbm

workflow :

    - Technology


---

# Configure

# Configuring SPM
Enterprise-Wide Deployment {#ariaid-title1}

Release version: Australia  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read  
Configuring Enterprise-Wide Deployment (EWD) involves creating partitions, defining partition criteria for supported tables, and assigning partition roles to users or user groups to enforce function-level data
separation.

## High-level configuration process {#configure-ewd__section_config_process}

EWD configuration is an administrative activity that requires planning before implementation. To achieve data separation with EWD, complete the following steps in order:

1. Create a partition record with assigning a new or existing role to it. For details, see [Create and configure a partition](https://servicenow-prod.fluidtopics.net/9OVKfJ0_6~5TJ~KxmfzxIA "Create a partition to control record visibility for users within a specific function, such as a department or business unit.").
2. Configure partition criteria for each supported table that you want to define data partitioning for that partition. For details, see [Assign partition role for access to the partition](https://servicenow-prod.fluidtopics.net/G16OXmkMBigNPOCNHRsyzw "Assign a partition role to users or user groups to grant them access to records within a specific partition.").
3. Assign the partition role associated with the partition record to the users or user groups who should have access to those partitioned tables. For details, see [Verify partition configuration](https://servicenow-prod.fluidtopics.net/bU85nFRZaeNuySacRShRBA "Verify that partitions are configured correctly by impersonating users with different partition roles and checking that record visibility is enforced across all workspaces.").

   Repeat this process for each function partition you need to create. For example, create separate partitions for IT Operations and HR Learning and Development.
4. Update the existing records in the project, demand, programs, portfolios, and planning item tables with partition details by running the scheduled job. For details, see [Update partition details for existing records](https://servicenow-prod.fluidtopics.net/nT6Ey~89t4jDLemYwJTp4Q "Update existing records in the project, demand, programs, portfolios, and planning item tables with partition details by running the Update existing records with partition details scheduled job.").
5. Enable the additional security that extends partition access controls across APIs, agentic workflows, indirect references, and unpartitioned parent tables. This configuration requires installation of Extended Security for Enterprise-Wide Deployment. For details, see [Enable additional security for partitions](https://servicenow-prod.fluidtopics.net/0KKA4giiZgJ07LnMmmqEow "Enable additional ACL enforcement for partitioned tables to strengthen access control validation. Select the tables where you want to apply enhanced security.").

Important:  
Apply partition configuration changes and role assignments during a maintenance window when users are not accessing the instance, to ensure record visibility updates take effect correctly.

## Partition configuration checklist {#configure-ewd__section_prereqs}

Before configuring Enterprise-Wide Deployment, ensure the following are in place:

* The EWD admin \[sn_spm_ewd.ewd_admin\] role assigned to you.
* The reference column to use as the partition criteria field is identified. All partitions on the same table must use the same reference column --- for example, Department for all partitions on the Project table.
* The users or user groups that should have access to each partition are identified.
* A plan for handling existing records is in place. After configuring partitions, run the Update existing records with partition details scheduled job to populate partition values on historical records.

Important:  
Once partition criteria is configured for a table, the criteria field becomes read-only and cannot be changed for subsequent partitions on that table. Plan your partition structure accordingly before creating partitions.

## Supported tables for partition criteria {#configure-ewd__section_supported_tables}

Partition criteria can be configured for the following core tables:

* Project \[pm_project\]
* Demand \[dmn_demand\]
* Program \[pm_program\]
* Portfolio \[pm_portfolio\]

Related records and sub-entities for these tables automatically inherit the partition value from the parent record. For a full list of tables in scope, see [Supported tables for partition](https://servicenow-prod.fluidtopics.net/xSUbN9ilEuJYpcQOF9yCEg "Several tables are supported for partition using Enterprise-Wide Deployment, including direct and indirect related tables for each entity.").

## Supported workspace versions {#configure-ewd__supported-workspace-versions}

Partition enforcement is supported in the following workspaces. For partition enforcement to function in a workspace, that workspace must be installed at the specified minimum version:

* Project Workspace (7.3.0)
* Portfolio Planning Workspace (8.15.0)
* Strategic Planning Workspace (4.15.0)
* Resource Management Workspace (5.7.0)