• HOME
  • INTEGRATIONS
  • SDK
  • API DOCS
No results for ""
EXPAND ALL
CLOSE
launchdarkly.com

EDIT ON GITHUB

Resources in custom roles

Read time: 1 minute
Last edited: Feb 12, 2020

Overview

This topic explains how custom roles use resources.

Almost everything in LaunchDarkly is a resource, including:

  • Projects
  • Feature flags
  • Environments
  • Metrics
  • Custom roles

When you change a feature flag's rollout rules, or rename an environment, you are accessing a particular resource.

Understanding the resource specifier syntax

LaunchDarkly uses a resource specifier syntax to name resources or collections of resources. This is a precise but flexible categorizing taxonomy that allows you to name any resource in a way that accurately reflects the information structures your organization uses.

The pattern looks like this:

1resource-type/name;tag1,tag2

The example above shows two tags separated by a comma. Tags are also optional. If you don't need to use any tags, you can omit the semicolon (;) and all content following.

In the example below, we create a resource that names all of the projects in an account:

1proj/*
Syntax supports wildcards

The resource syntax accepts globs, so you can name collections of resources with *. You can also name a specific project by ID.

In the example below, we name a project by the default ID.

1proj/default

You can name sets of resources all the way down to the tag level.

In the example below, we name all projects with the mobile tag.

1proj/*;mobile

Scoping resources

The term scoping refers to granting or restricting permissions and access to a resource based on relationships the resource has. Resources can be scoped within parent resources.

For example, metrics are scoped within a project, and feature flags are scoped within a project and environment.

Name scoped resources by using the resource syntax structure depicted below.

1resource-type/name;tag1,tag2:resource-type/name;tag3,tag4,tag5

In the following example, we name all feature flags across all environments:

1proj/*:env/*:flag/*

In the example above, proj/*:indicates that all named projects will be included in the list of results. env/*: indicates that all environments will be included in the list of results. flag/*: indicates that all flags will be included in the list of results.

Because of the range of resources referenced in this example, we can say it has very broad scope.

For a more refined example, we could name all feature flags whose keys start with ops_:

1proj/*:env/*:flag/ops_*

Understanding resource types and scopes

Resource TypeResource Scope
projTop-level resource. Projects have no parent resource. Write it as proj/*.
envA child resources of projects. Write it as proj/*:env/*.
metricmetric is a child resource of projects. Write it as proj/*:metric/*
membermember is a top-level resource. Write it as member/*
tokentoken is a child resource of members. Write it as member/*:token/*.
rolerole is a top-level resource. Write it as role/*
flagflag is a child of both a project and environments. Write it as proj/*:env/*:flag/*
segmentsegment is a child of both a project and environments. Write it as proj/*:env/*:segment/*
integrationintegration is a top-level resource. Write it as integration/*
webhookwebhook is a top-level resource. Write it as webhook/*
useruser is a child of both a project and environments. Write it as proj/*:env/*:user/*
code-reference-repositorycode-reference-repository is a top-level resource. Write it as code-reference-repository/*
destinationdestination is a child of both a project and environments. Write it as proj/*:env/*:destination/*.
acctacct is a unique resource specifier representing modifications to your account itself, such as managing