Creating a custom role/acl for creating Releases
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
How might one go about creating a custom role and ACL for DPR? The customer wants to enable business users, scrum masters, developers to create releases on their own terms. If a custom role and ACL were to be created to grant that ability, what are somethings that I need to watch out for?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Kevin,
This is a request that balances "Agile Autonomy" against "Governance." While technically straightforward, opening up Release creation to a broad audience has significant implications.
Here is the technical "How-To" followed by the critical "Watch-outs."
Part 1: The Technical Implementation
Since DPR is a scoped application (sn_dpr), ensure you are in the correct scope before starting.
Create the Custom Role:
Create a role, e.g., u_dpr_creator.
Tip: You might want to nest this role. If these users also need to read other DPR data, consider making this new role contain sn_dpr.reader (if OOB structure permits) so you don't have to rebuild Read ACLs.
Create/Modify ACLs: You need to grant Create and Write access.
Table Level: Create a record/create ACL for sn_dpr_model_release (or the specific table you are targeting). Add your u_dpr_creator role.
Field Level: Create a record/write ACL for sn_dpr_model_release.* (or specific fields). Without this, they can create the record but might not be able to fill in the form.
Part 2: The Watch-outs (Critical)
Opening this up brings three major risks:
1. Licensing Implications (Most Important)
Release Management usually falls under specific licensing models (ITSM Pro, SPM, or DevOps depending on the contract).
Risk: Assigning a role that allows creating or editing Releases might trigger a Fulfiller/Planner license consumption for "Business Users" or "Developers" who otherwise might only have free/requester roles.
Check: Verify with your account rep if these users are covered.
2. Data Governance & Sprawl
Risk: If 50 developers can create releases "on their own terms," you will likely end up with duplicate releases, inconsistent naming conventions, and orphaned records.
Mitigation: If you proceed, ensure you have Business Rules or Client Scripts enforcing naming standards and mandatory fields (e.g., Application Product Model must be populated).
3. Workspace Visibility
DPR is workspace-heavy. Giving an ACL allows them to write to the database, but it does not automatically grant them access to the Digital Product Release Workspace.
You will likely need to modify the Audience records in the "Now Experience Framework" to allow this new custom role to even see the workspace to click the "New" button.
Recommendation: The "Record Producer" Alternative
Instead of giving them raw backend/workspace access (ACLs + Roles), consider building a Service Catalog Record Producer:
User Experience: Business users/Devs go to the Portal/Center, fill out a simple form ("Request New Release"), and submit.
Backend: The script creates the Release record.
Benefit: You control the input validation, you don't need to expose the complex Workspace UI, and it often simplifies the licensing discussion (though check this).
Hope this helps you guide the customer!
If this response helps you achieve your requirement, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.
Best regards,
Brandão.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi @Kevin Tran ,
Find the solution below.
- Create a Custom Role: Navigate to User Administration > Roles and create a new role, such as u_dpr_release_creator.
- Identify the Target Table: Digital Product Release typically utilizes a table named sn_dpr_release (or similar, depending on your version).
- Configure ACLs: You must create or modify the following Table-level ACLs specifically for your custom role:
- Create: Grants permission to click "New" and initiate a record.
- Read: Necessary for users to see the records they or others have created.
- Write: Allows users to edit and save fields on the release form.
- Default Deny Model: ServiceNow uses a "default deny" security model. If you create a new ACL for a table, ensure you are not accidentally blocking existing users (like admins) who previously had access.
- Licensing Implications: In 2026, many ServiceNow features are tied to user roles. Ensure that granting a custom role to "Business Users" does not inadvertently trigger a need for a more expensive Fulfiller license (e.g., ITSM or ITBM licenses).
- Data Integrity & Policies: Custom roles bypass traditional UI-level restrictions. Use Data Policies instead of just UI Policies to ensure mandatory fields (like Product, Version, or Template) are populated regardless of how the record is created.
- Avoid ACL "Bloat": Do not create separate ACLs for every field (table.*) unless strictly necessary. Start with Table-level access and only use field-level ACLs for sensitive data like financial costs or security keys.
- Inherited Permissions: Check if the release table inherits from the task table. If it does, your custom ACL might compete with existing task ACLs. Always test using the Security Debugger to see which rule is winning.
