Default Approvers

Control & Direction

Default Approvers configure who is responsible for approving phase transitions and requirement sign-offs across your lifecycle templates. Rather than assigning approvers individually on every project, you define default approval rules at the tenant level and optionally override them at the project level. This provides a consistent governance baseline while allowing flexibility for projects with unique approval needs.

Default Approvers integrate with Lifecycle Templates (template phase definitions), Lifecycle Builder (stage approval gates), and Projects (project-level overrides).

Approver settings page

Navigate to Lifecycle > Default Approvers to manage approval configurations. The page is organized into two sections:

Default Phase Approvers — defines who must approve transitions between lifecycle phases
Default Requirement Approvers — defines who must approve individual requirements within a project phase

Both sections display the current configuration and allow you to add, modify, or remove approver rules.

Approval scopes

Each approval configuration targets one of two scopes, determining what type of sign-off the approver is responsible for.

Scope	Description
Phase Approval	The approver must sign off before a project can transition from one lifecycle phase to the next. This is the gate that controls progression through the lifecycle stages.
Requirement Approval	The approver must sign off on individual requirements within a phase. This is a more granular control used when specific deliverables or conditions need independent approval before the phase can advance.

Tenant-level vs. project-level configuration

Approval rules are defined at two levels, with project-level settings taking precedence when they exist.

Level	Description
Tenant	The default configuration that applies to all projects across your organization. Tenant-level rules provide a baseline governance standard.
Project	An override configuration applied to a specific project. When a project has its own approver configuration for a given phase and scope, it replaces the tenant-level default for that combination.

This two-tier structure means you can set organization-wide defaults — such as requiring the CISO to approve all phase transitions — while allowing individual projects to define their own approvers when the standard rules do not apply.

Configuring approvers

Select the phase

Choose the lifecycle phase that the approval rule applies to. Each phase in your lifecycle templates can have its own set of approver rules.

Choose the scope

Select whether the rule governs Phase Approval (transition between phases) or Requirement Approval (individual requirement sign-off within a phase).

Define the approver configuration

The approver config specifies who must approve and under what conditions. Configuration options include:

Specific users — named individuals who must provide approval
Role-based approvers — users assigned to a particular role (e.g., project owner, security lead) who are responsible for approval
Multi-approver rules — require approval from multiple parties, either all listed approvers or a minimum threshold

Save the configuration

Save the approver configuration. It takes effect immediately for tenant-level rules. For project-level overrides, the configuration applies only to the specified project.

How overrides work

When a project reaches a phase transition or requirement approval checkpoint, the system checks for a project-level configuration first. If one exists for that phase and scope combination, it is used. If no project-level configuration exists, the tenant-level default is applied. If neither level has a configuration for that phase and scope, the transition or approval proceeds without a gate.

This fallback behavior ensures that governance is applied consistently while avoiding the need to configure every project individually.

Permissions

Managing default approver configurations requires the lifecycle:manage permission. Users with this permission can create, edit, and delete approver rules at both the tenant and project levels. Users with read-only access can view the current configurations but cannot make changes.