ServiceNow Update Sets and Release Management: Roles, Responsibilities and RACI

Why RACI matters for release management

Release Management coordinates changes across environments (dev, test, production) and teams (developers, testers, infrastructure, business). Without clear roles, changes get lost, testing is incomplete, and production deployments fail. A RACI matrix (Responsible, Accountable, Consulted, Informed) ensures someone is accountable for each part of the process and responsible for doing it. When roles are unclear, conflicts arise about who should have made a decision or why something was missed. Organizations without clear release management roles experience longer deployment cycles, higher defect rates, and difficulty meeting SLAs because work is duplicated or delayed waiting for unclear approvals.

Core roles in release management

Release Manager: coordinates the release from planning through production deployment. Accountable for delivery schedule and quality. Responsible for communication and stakeholder coordination. Acts as the central point of contact for all release-related decisions. The Release Manager decides when the release is ready to proceed to the next phase.

Developer: develops changes in development environment. Responsible for creating update sets and initial testing. Accountable for code quality and ensuring that changes do not introduce unintended side effects. Developers must follow coding standards and document their changes clearly so other team members understand what was modified.

QA Lead: leads testing in test environment. Accountable for test coverage and defect identification. Responsible for test planning and execution. Determines whether a release is ready for production based on test results and quality gates. QA leads design test cases, execute them, and escalate critical defects.

Infrastructure Lead (on a hosted instance, the platform or environment lead): manages the development, test and production instances, clones and refreshes, and the update set promotion path. Accountable for environment stability. Responsible for deployment readiness and the back-out plan; database operation and backups are performed by ServiceNow as the hosting provider. The Infrastructure Lead ensures that deployment procedures are safe and that rollback plans are in place in case problems occur.

Business Analyst: gathers requirements and validates that deployed changes meet requirements. Accountable for business acceptance. Ensures the release solves the business problem it was intended to address. Business Analysts may also serve as subject matter experts for testing, validating that functionality works as intended from a business perspective.

RACI matrix: key processes

Change Planning: Release Manager is Accountable for planning the release timeline and scope. Developers and QA are Consulted on technical feasibility and schedule. Business Analysts are Informed of planned changes affecting their areas and customer-facing functionality. This ensures the release scope is realistic and stakeholders know what to expect.

Development and Update Set Creation: Developer is Accountable and Responsible for developing and documenting changes. Release Manager is Consulted on schedule to ensure deadlines will be met. QA is Informed of what was developed so they can design test cases. This prevents scope creep and ensures the developer owns their code quality.

Testing and Defect Management: QA Lead is Accountable and Responsible for testing the release. Developer is Consulted on defects found during testing. Infrastructure is Consulted on environmental issues that might prevent testing. This ensures thorough testing and clear accountability for test results.

Deployment Planning: Release Manager is Accountable for overall deployment planning. Infrastructure Lead is Responsible for deployment execution and coordination. Business Analysts are Consulted on change windows and business impact. This ensures deployment coordination and stakeholder awareness.

Production Validation and Sign-Off: Release Manager is Accountable for release sign-off. Business Analysts are Responsible for validating that changes work in production and meet business requirements. QA is Consulted on acceptance criteria verification. This ensures someone verifies the release worked in production before it is considered complete.

Common pitfalls and how to avoid them

Pitfall 1: Roles not documented or not understood. Release team members think someone else owns a task, leading to gaps or duplicated work. Solution: Document the RACI matrix, review it with the team, and reference it during release planning. Train new team members on the roles and responsibilities established in your RACI matrix.

Pitfall 2: Conflicting authority. Two people claim to be Accountable for the same decision, or unclear who has final authority. Solution: Review your RACI matrix and ensure only one person is Accountable for each process step. If two roles share authority, define this explicitly: one is Accountable, the other is Consulted or Responsible for specific sub-tasks.

Pitfall 3: Escalation paths not defined. When a critical defect is found near deployment, it’s unclear who decides whether to proceed or delay. Solution: Add escalation rules to your RACI matrix: establish criteria for when defects trigger escalation, define who is involved in escalation decisions, and set thresholds for approval by each authority level.

Pitfall 4: RACI not adapted as your release process evolves. Your process changes, new systems are added, but the RACI matrix is never updated. Solution: Review and update your RACI matrix quarterly or when significant process changes occur. Involve the team in updates so ownership is clear and agreed.

Mapping roles onto a small team

A RACI chart assumes a separate person for each role, and many release teams do not have that. In a small platform team one administrator may build the change, run the test and push it to production. That is workable for a trivial change and dangerous for a significant one, because the person who built the change is the only one checking it. The useful exercise is to decide which combinations of roles can safely sit with one person and which must be split, then fill the gaps with a named backup rather than pretending the gap does not exist.

Making sure every named role has a backup

A named role with a single holder is a risk the chart does not reveal. For each role, name a backup who has performed the duties at least once, and record when the backup last did so. Rotate people through the duties on a schedule so that handover does not depend on memory. The backup does not need the same authority in ordinary times, but they must be able to step in when the primary is unavailable during a release window.

Escalation when roles disagree

Conflicts between roles are normal, and the chart should say how they end. A reliable escalation route avoids the pattern where a disagreement drags on until someone forces a decision under deadline pressure. Use an ordered route:

1. The people closest to the change try to settle the disagreement and write down what each side is concerned about.
2. If unresolved, the release manager decides within the release process and records the reason.
3. If the disagreement concerns risk to a regulated area or a live service, it goes to the governance owner, who may hold or pause the release.
4. Any decision that overrides a recorded concern is reviewed after the release, with the concern and the outcome both written down.

Keeping the chart honest over time

Roles drift. People change teams, new integrations introduce new responsibilities, and the chart still shows last year’s arrangement. Check the chart after each significant release and after any organizational change, and ask whether the named people are still doing what the chart says. A chart that is out of date is worse than none, because people will trust it. The CAB decisions article covers how change review should work, which is the approval side of this chart.

Frequently asked questions about release roles

Can a developer also be the release manager?

It is possible in a very small team, but the developer should not approve their own changes or decide whether a restricted change goes ahead. Where that separation cannot be achieved, add a reviewer from outside the team for every change above the routine tier.

Who should approve changes when the release manager is on leave?

The backup named in the chart, provided they have performed the approval role before. Handing approval to someone with no experience of it, under pressure, is a common route to an avoidable production problem.

Is a separate change manager always required?

No. In a small organization the release manager may hold both duties. What matters is that the decision to approve is distinct from the work of building and deploying the change.

Next step for defining your release roles

The platform governance charter guide shows how role decisions can be recorded at the level of the whole platform.