Delegated authority

Enable cross-functional collaboration by granting teams authority to manage flags in projects they do not own. This strategy empowers support, security, and operations teams to coordinate releases without bottlenecking engineering teams.

Overview

Delegated authority uses LaunchDarkly’s custom roles and approval workflows to grant specific teams permission to manage subsets of flags across multiple projects. This enables cross-functional coordination while maintaining security and governance.

When to use delegated authority

Use delegated authority when:

• Cross-functional teams need to coordinate releases
• Customer success or support teams manage early access programs
• Database administrators control schema migration flags
• Security engineers manage security features
• Teams need to modify flags in projects they do not own

How delegated authority works

Each coordination strategy has two parts:

Platform

What teams do in LaunchDarkly:

Members are delegated authority to manage a subset of flags or segments inside other teams’ projects through:

• Custom roles with scoped permissions
• Approval workflows for change review
• API access for automation

Delegated authority can be combined with prerequisite flags.

Application

What developers implement: Applications evaluate flags as usual. No additional code is required.

Delegated authority scope

Delegated authority works across boundaries:

Both teams must have access to LaunchDarkly.

Use cases

Customer success early access programs

Empower customer success teams to manage early access enrollments without engineering involvement.

Example scenario:

Customer success team manages beta access to new analytics dashboard.

Setup:

1. Create flag: Release: Analytics Dashboard
2. Create custom role: Customer Success - Early Access
3. Grant role permission to modify targeting rules for flags tagged with early-access
4. Tag Release: Analytics Dashboard with early-access
5. Assign role to customer success team members

Result:

Customer success can add customers to early access beta programs by modifying targeting rules. Engineering maintains control over flag creation and removal.

Database administrators schema migrations

Enable database administrators to signal migration completion across multiple services.

Example scenario:

Database team manages schema migration flags across multiple microservice projects.

Setup:

1. Create flags in each project: DB: User Table Migration Complete
2. Create custom role: DBA - Schema Migrations
3. Grant role permission to manage flags tagged with schema-migration
4. Assign role to database administrators

Result:

Database administrators can signal when migrations are complete. Engineering teams evaluate these flags to enable new code that depends on schema changes.

Security engineers rapid response

Allow security team to quickly enable security mitigations across multiple projects.

Example scenario:

Security team needs ability to enable rate limiting or security features in response to incidents.

Setup:

1. Create flags in each project: Security: Enhanced Rate Limiting
2. Create custom role: Security - Incident Response
3. Grant role permission to manage flags tagged with security
4. Configure approval workflow with security team as reviewers
5. Assign role to security engineers

Result:

Security engineers can request activation of security features during incidents. Approvals ensure changes are reviewed while enabling rapid response.

Frontend team segment management

Grant frontend teams authority to manage browser support segments across backend services.

Example scenario:

Frontend team maintains list of supported browsers across multiple services.

Setup:

1. Create segment: Supported Browsers in each relevant project
2. Create custom role: Frontend - Browser Support
3. Grant role permission to modify segments tagged with browser-support
4. Assign role to frontend team members

Result:

Frontend team can update supported browser list once. Backend services use the segment for targeting decisions.

Implementation steps

Step 1: Identify delegated permissions

Determine what permissions to delegate:

• Which flags or segments can be modified
• Which environments can be accessed
• Whether changes require approval
• Which projects are in scope

Step 2: Create custom role

Create a custom role with scoped permissions:

1. Navigate to Account settings → Roles
2. Click Create role
3. Provide a descriptive name
4. Configure permissions using policies

Example policy for early access management:

[
  {
    "effect": "allow",
    "actions": ["updateOn", "updateFallthrough", "updateTargets"],
    "resources": ["proj/*:env/production:flag/*;early-access"]
  }
]

This policy allows:

• Updating targeting rules
• Only in production environment
• Only for flags tagged with early-access
• Across all projects

Step 3: Configure approval workflows

Require approvals for delegated changes in production:

1. Navigate to environment settings
2. Enable Approvals
3. Configure approval requirements:
   • Minimum number of reviewers
   • Required reviewers
   • Service tokens excluded from approvals
4. Save configuration

Step 4: Assign role to team

Grant the custom role to appropriate team members:

1. Navigate to Account settings → Team
2. Select team member
3. Click Add role
4. Select the custom role
5. Save changes

Step 5: Document delegation

Create documentation for delegated teams:

• Which flags they can modify
• How to request changes
• Approval process and timeline
• Escalation procedures
• Examples of appropriate changes

Example configuration

Scenario: Customer support troubleshooting

Custom role: Support - Customer Overrides

Policy:

[
  {
    "effect": "allow",
    "actions": ["updateTargets", "updateOn"],
    "resources": ["proj/support-enabled:env/production:flag/*"]
  }
]

Tagged flags:

• Enable Advanced Logging
• Enable Debug Mode
• Enable Experimental Features

Workflow:

1. Support receives customer issue requiring advanced diagnostics
2. Support creates approval request to enable advanced logging for specific customer
3. Engineering reviews and approves request
4. Support enables logging for customer
5. After troubleshooting, support disables logging

Best practices

Use tag-based permissions

Grant permissions based on flag tags rather than specific flag names. This allows new flags to inherit permissions automatically:

{
  "resources": ["proj/*:env/production:flag/*;customer-success"]
}

Require approvals in production

Always require approvals for delegated changes in production environments. This provides an audit trail and ensures changes are reviewed.

Limit environment access

Grant delegated access only to necessary environments:

{
  "resources": ["proj/*:env/production:flag/*"]
}

Avoid granting access to development or test environments unless specifically needed.

Document flag ownership

Maintain clear documentation of flag ownership:

• Primary owner responsible for flag lifecycle
• Delegated teams authorized to modify targeting
• Change approval process
• Escalation contacts

Use flag descriptions

Document delegation in flag descriptions:

Flag: Enable Advanced Logging

Owner: Platform Engineering
Delegated to: Customer Support for troubleshooting
Requires approval: Yes
Approval reviewers: @platform-oncall

Monitor delegated changes

Track changes made through delegated authority:

• Review approval requests regularly
• Monitor flag evaluation metrics
• Audit delegated access quarterly
• Revoke access when no longer needed

Troubleshooting

Team member cannot modify flags

Symptom: Team member with delegated role cannot modify flags they should have access to.

Possible causes:

1. Flags not tagged correctly
2. Role policy scope too restrictive
3. Approval workflow blocking direct changes
4. Insufficient base permissions

Solution:

1. Verify flags have the required tags
2. Review role policy to ensure it matches flag resources
3. Check if approval workflow requires request instead of direct modification
4. Verify team member has base permissions to access the project

Approval requests not reaching reviewers

Symptom: Approval requests are created but reviewers do not receive notifications.

Possible causes:

1. Reviewers not configured in approval workflow
2. Notification settings disabled
3. Role does not require approvals
4. Approval workflow not enabled

Solution:

1. Verify approval workflow configuration includes required reviewers
2. Check reviewer notification settings in account preferences
3. Review role policy for approval requirements
4. Confirm approvals are enabled in the environment

Excessive approval requests

Symptom: Delegated team creates many approval requests that engineering teams struggle to review.

Possible causes:

1. Delegated permissions too restrictive
2. Approval workflow too strict
3. Poor communication about appropriate changes
4. Missing self-service capabilities

Solution:

1. Review if delegated permissions should allow direct changes for low-risk modifications
2. Adjust approval requirements such as reducing required reviewers
3. Provide training and documentation on appropriate use
4. Consider expanding delegated permissions for routine changes

Combining with other strategies

Delegated authority works well with other coordination strategies:

Delegated authority with prerequisite flags

Scenario: Product marketing team controls release timing for coordinated product launches.

Setup:

1. Engineering creates prerequisite flags for feature components
2. Engineering creates keystone flag with product-marketing tag
3. Custom role grants product marketing team permission to modify keystone flag
4. Product marketing controls launch timing by enabling keystone flag

Result:

Engineering maintains control over component flags and technical implementation. Product marketing controls the coordinated release without engineering involvement.

Delegated authority with request metadata

Scenario: API consumers can request custom targeting rules for their client versions.

Setup:

1. API service evaluates flags using request metadata
2. Custom role grants API consumers permission to create targeting rules
3. Approval workflow requires API team review
4. Consumers create approval requests for custom targeting

Result:

API consumers can request accommodations for their specific client versions. API team reviews and approves requests without custom code changes.

Related documentation

To learn more about roles and permissions:

• Custom roles
• Approval workflows
• Teams

To learn about project architecture:

• Projects
• Coordinating releases