# 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: | Architecture | Supported | |--------------|-----------| | Within a single project | Yes | | Across multiple projects | Yes | | Outside of projects | No | 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:** ```json [ { "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:** ```json [ { "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: ```json { "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: ```json { "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](https://launchdarkly.com/docs/home/account/roles)* - *[Approval workflows](https://launchdarkly.com/docs/home/releases/approvals)* - *[Teams](https://launchdarkly.com/docs/home/account/teams)* To learn about project architecture: - *[Projects](../../platform-readiness/projects-and-environments/projects.md)* - *[Coordinating releases](./index.md)*
Last modifiedLast reviewedReview due
Last commit: d319a7d