---
sourceDocument: Brazil IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/it-service-management

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# Release for a product or service

# Release for a product or service {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 8 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 Release for a product or service

A release in ServiceNow groups all tasks related to a specific product or service version, including projects, epics, stories, and incidents.
The Digital Product Release module offers two primary release processes---timeline-oriented and stage-oriented---to help manage and execute releases efficiently.
Releases are divided into phases, each with required tasks, approvals, and policies to ensure readiness for deployment.
Show full answer Show less  

## Release Processes

**Timeline-oriented Release Process:** Designed for releases with fixed deadlines, this process helps prioritize tasks, allocate resources, and track progress against a schedule. Phases progress sequentially, with only one phase active at a time. Tasks within phases can be executed sequentially or concurrently, controlled by the system property `sndpr.sequentialtaskexecution`. After completing all phases, the release moves to Review, then Completed.

**Stage-oriented Release Process:** Focuses on meeting objectives and features rather than strict deadlines, allowing phases to progress based on readiness criteria. Phases start manually, and tasks can be processed sequentially or concurrently. Releases can be restarted from any previously completed phase to adjust goals based on feedback. The release completes after all phases are reviewed and approved.

## Release Types

**Single Product or Service Release:** Manages the release of individual products or services, suitable for smaller or less complex offerings.

**Multi-product Release:** Enables simultaneous releases of multiple products under a primary release. Each product has its own child release with aligned phases and policies. Phase progression is synchronized so that no product advances beyond the main release phase, ensuring coordinated rollout. Products can be added or removed dynamically, with child releases created or cancelled accordingly.

## Policy Execution and Compliance

Each release phase has policies that must be executed and validated. Policy statuses include Not run, In progress, Compliant, Non-compliant, and Compliant with exception. In multi-product releases, policy statuses are aggregated to determine overall release compliance, where any non-compliance blocks advancement until resolved.

## Access Control

Restricted access can be enabled at the product level to limit who can view releases and related records. Product owners configure restricted access and define a product team with release user roles. This setting is inherited by releases and multi-product releases, ensuring only authorized users have access. Release and product owners can modify access, while administrators have override capabilities.

## Release Lifecycle

Releases transition through defined states from creation to completion, including a pause option via the On Hold state. This maintains data integrity while temporarily halting progress.

## System Properties

Specific system properties control automated transitions and actions during release phases, such as `sndpr.stageworkflowautotransition` and others, enabling customization of release workflows.

## Practical Benefits for ServiceNow Customers

* Choose between timeline or stage processes based on your product's scheduling needs.
* Manage single or multiple product releases with coordinated phase progression and compliance tracking.
* Ensure quality and readiness through structured task, approval, and policy enforcement during each phase.
* Control access to sensitive release data with configurable restricted access settings.
* Track release progress clearly with defined states and system-managed transitions.  
A release groups all the tasks (projects, epics, stories, enhancements, defects, problems, incidents, and so on) planned for a specific version of a product or service. Digital Product Release provides two different processes: timeline-oriented and stage-oriented, to help you in executing your releases.
A release is divided into a series of phases. During each phase, a defined list of tasks, approval processes, and policies must be fulfilled.

A defined release process ensures that the work items in releases are built, tested, and are ready for deployment.

## Timeline-oriented release process {#dpr-product-release__id_a2m_fgc_b2c}

Timeline-oriented process is suitable for creating releases that have fixed deadlines and follow a strict schedule.{#dpr-product-release__dpr-timeline-rls-p1}  
This process helps you prioritize tasks, allocate resources, and track progress against the timeline so you can make adjustments as needed to stay on track. Use this release process to:

* Set clear deadlines for each stage of your deployment, so you can plan and execute your rollout smoothly.
* Keep your team on track by defining clear goals, so you can manage your resources effectively.
* Track your progress against key dates, and adjust your plans as needed to stay on schedule.
{#dpr-product-release__ul_cbf_xlw_fbc}  
The following is the general flow that a timeline-oriented release goes through:

* The flow starts with the first phase in the Pending state, which is the default state. The state of the phase moves to In Progress when it starts on the planned start date.  
  Tasks in the phase are processed based on the system property sn_dpr.sequential_task_execution:
  * true: Tasks in the phase are processed in sequential order. At the start of a phase, the task with the lowest order in it is set to the Open state. After this task is completed, the next task in the order is opened. This process continues for the remaining tasks in the phase. If the task is an approval task, the state is moved to the Requested state.
  * false: Tasks in the phase are not processed in a sequence. Instead, all its tasks are set to the Open state at the start of the phase.
  {#dpr-product-release__ul_a2t_vsm_lfc}
* When all tasks are completed and policies are compliant, the phase ends automatically on its planned end date. The phase state updates to the Completed state.
* After the current phase is completed, the next phase moves to the In Progress state. Only one phase can be in progress at a given time.
* When all phases in the release are completed, the release moves to the Review state.
* When the review of the release is completed, the release moves to the Completed state.
{#dpr-product-release__ul_skt_c4f_lzb}

## Stage-oriented release process {#dpr-product-release__id_mms_fgc_b2c}

Stage-oriented process is suitable for creating releases that prioritize completing objectives and features over following a strict timeline.{#dpr-product-release__dpr-stage-rls-p1}

Certain products are not constrained by a specific time frame for how long they should remain in a particular phase. Releases for those products can follow the stage-oriented release process. This process
focuses on making sure that the product is ready to be released, rather than following a strict schedule or phase.{#dpr-product-release__dpr-stage-rls-p2}

You can finish a release as soon as the product meets the set criteria, instead of waiting for a specific timeline or phase to end. However, you must ensure that all aspects of the release, including
development, testing, and quality assurance, are done well to keep the product high quality.{#dpr-product-release__dpr-stage-rls-p3}  
Use this release process to:

* Set priorities for features and goals, instead of deadlines, so that you can adjust your plans throughout the development process.
* Restart the release from any of the previous phases to adjust goals and features based on testing results and user feedback.
* Track your progress by ensuring features are completed and the goals are met for a high-quality result.
{#dpr-product-release__ul_fgd_zlw_fbc}  
The following is the general flow that a stage-oriented release goes through:

* The flow starts with the first phase in the Pending state, which is the default state. The state of the phase moves to In Progress when you manually start it.  
  Tasks in the phase are processed based on the system property sn_dpr.sequential_task_execution:
  * true: Tasks in the phase are processed in sequential order. At the start of a phase, the task with the lowest order in it is set to the Open state. After this task is completed, the next task in the order is opened. This process continues for the remaining tasks in the phase. If the task is an approval task, the state is moved to the Requested state.
  * false: Tasks in the phase are not processed in a sequence. Instead, all its tasks are set to the Open state at the start of the phase.
  {#dpr-product-release__ul_syp_y5m_lfc}
* When the all tasks are completed and all policies are compliant or compliant with exceptions for the current phase, it automatically moves to the Completed state.
* After the current phase is completed, the next phase moves to the In Progress state. Only one phase can be in progress at a given time.
* If you encounter any issues at any point, you can restart from a previously completed phase. That phase and later phases are reset, including tasks and policy status.
* When all phases in the release are completed, the release moves to the Review state.
* When the review of the release is completed, the release moves to the Completed state.
{#dpr-product-release__ul_sdb_jcg_gbc}

## System properties to control the release processes {#dpr-product-release__section_dx2_l2g_gbc}

The following system properties control the initiation of automated actions during various stages of the release process.

* sn_dpr.stage_workflow_auto_transition
* sn_dpr.auto_transition_release_to_review
* sn_dpr.auto_transition_release_to_completed

{#dpr-product-release__ul_f2h_m2g_gbc}For more information about these properties, see [Digital Product Release properties](https://www.servicenow.com/docs/qMfA9yideWMGhKkulbQGkg "Configure the system properties to customize various features of Digital Product Release according to your organization's needs.").

## Single product or service release {#dpr-product-release__section_b3c_jwq_b2c}

A single product or service release enables you to release one product or service at a time. This release approach can be useful for smaller or less complicated products or services, as it makes the release process more focused and easier to manage. For more information, see [Work on a timeline-oriented release for a single product or service](https://www.servicenow.com/docs/iI0J72hsy3_Q_NeDy_G~oQ#dpr-work-release "Monitor and work on a release that follows the timeline-oriented release process to release a single product or service.") and [Work on a stage-oriented release for a single product or service](https://www.servicenow.com/docs/HYv_r9B4~uwEA3hYnL8jbQ#dpr-work-stage-release "Monitor and work on a release that follows the stage-oriented release process to release a single product or service.").

## Multi-product release {#dpr-product-release__section_xvn_kwq_b2c}

A multi-product release enables you to release different products at the same time. You can do this by including several individual releases for each product, all tied to a main release of a primary product or service. You manage
the phases and release readiness from the main release and track the collective progress. However, you can set the scope, track approvals, and run policies for each individual product or service release.

This release approach differs from release bundles, where you monitor the progress of multiple releases together but manage them independently.

For more information, see [Work on a timeline-oriented release for multiple products](https://www.servicenow.com/docs/X1w~EFlYXMPAiLuElYxxWQ "Monitor and work on a release that follows the timeline-oriented release process for multiple products.") and [Work on a stage-oriented release for multiple products](https://www.servicenow.com/docs/y7JNGIKOy1wXiFVj3Xw7PQ "Monitor and work on a release that follows the stage-oriented release process for multiple products.").  

Adding or removing a product from a multi-product release
:   You can add and remove products from a multi-product release after it is created. When you add a product, a child release is created with phases, tasks, and policies aligned to the main release. When you remove a product,
    the child release is cancelled and removed from the main release.

Phase management in a multi-product release
:
    In a multi-product release, the following phase synchronization rules apply:

    * Individual releases cannot advance past main release: An included product cannot complete a phase that is ahead of the main release's current phase.
    * Main release cannot advance past individual releases: The parent release cannot advance to the next phase if any included product has not yet reached the parent's current phase. All included products must be at the current phase before the main release can advance.These rules ensure that all products in a multi-product release progress through phases in a coordinated manner.

    {#dpr-product-release__ul_rpn_3qb_k3c}

    When a product is added to a release that is already in progress, the newly added product starts at the earliest phase. The system automatically executes the policies mapped to each phase sequentially:

    * If all policies for a phase are compliant, the phase is completed and the release advances to the next phase.
    * This process repeats through each phase until the product either catches up to the parent release's current phase or a policy evaluation fails.
    * If a policy evaluation fails, the product's phase remains at the non-compliant phase and the status shows as Non Compliant --- policy execution failed. You must resolve the non-compliance before the product can advance further.This can be done by either making the policies compliant or using the Complete phase action to force completion.
    {#dpr-product-release__ul_dw5_1pb_k3c}

Policy execution lifecycle and status aggregation
:   Policies mapped to release phases follow a defined lifecycle during execution:

    * Not run: The policy has not been executed yet.
    * In progress: The policy execution is underway.
    * Compliant: The policy passed validation.
    * Non-compliant: The policy failed validation.
    * Compliant with exception: The policy failed but an approved exception is in place.

    {#dpr-product-release__ul_policy_lifecycle}

    The policy run status for all primary and included products is aggregated to determine the overall policy status of the main release. The aggregation follows a priority hierarchy where a non-compliant status in any
    product results in an overall non-compliant status for the release.

    For more information, see [Policy status aggregation in a multi-product release](https://www.servicenow.com/docs/WEWTu93q8EB6~OYIldIpUw "In a multi-product release, the policy run status of releases for all primary and included products are rolled up to the policy status of the main release.").

## Restricted access for releases {#dpr-product-release__section_restrictedaccessrelease}

Product managers and release managers can limit who can view a release and its related records by enabling restricted access for a product.  
Restricted access is configured at two levels:

Product level
:   A product owner configures whether restricted access is enabled for releases created under that product. The product settings also define a default product team, consisting of individual users and user groups. Only users
    with the sn_dpr_model.release_user role can be added to the product team.

Release level
:   When a release is created for a restricted-access product, the restricted access setting and the product team are copied to the release as the initial release team. The release owner or the product owner can modify the
    release team after creation. The Restricted access for releases enabled checkbox and the Release team field appear in the Details tab under the
    Overview section of the Release form.

In a multi-product release, access control is inherited from the main release. All stakeholders listed in the main release's release team get read access to all individual releases and their associated records. Individual release
fields for restricted access and release team are read-only. When you add a product to a multi-product release with restricted access, release team members from the new release are automatically added to the main release team.  
The following users can modify restricted access settings:

* On a product, in release settings: product owner only
* On a release, in release details: release owner or product owner
* System administrators can override both settings
{#dpr-product-release__ul_roles_modify}Product managers and release managers can read restricted access settings but cannot change the product team or release team members.

For more information on setting up restricted access at product level, see [Configure product-level release settings](https://www.servicenow.com/docs/OdWETvShe4Od0AhO_GsfPQ "Configure release settings for a product or service that are applied whenever a release is created or executed for that product.").
* **[Release states](https://www.servicenow.com/docs/8vcz9HjFf6T0sDWRnUjxJw)**   
  A release moves through a defined set of states, from creation to closure. The On Hold state lets you pause a release temporarily without losing task, policy, or association data.

**Related concepts**   

* [Managing timeline-oriented releases](https://www.servicenow.com/docs/kyT2bdv3uKy~tIjuMT4saA "Managing a timeline-oriented release involves following a series of deadlines and milestones and adjusting as necessary to keep your release on track.")
* [Managing stage-oriented releases](https://www.servicenow.com/docs/tCDbtEv_hE5~vwog1Z3iIw "Managing a stage-oriented release involves completing objectives and closing the release when the work is done and meets the defined release criteria, rather than waiting for the planned end date.")
* [Managing multiple releases through release bundles](https://www.servicenow.com/docs/MdEA131V7hlpuTG_6ik18g "Release bundles help you to group multiple releases to track and manage them concurrently from a single place.")  
**Related tasks**   

* [Create a release for a product or service](https://www.servicenow.com/docs/QzYj2GJGzemN4Q0s7UBCLw "Create a product or service release when all planned product enhancements and product features are ready.")