Core Concepts

Data Model

Organization

• All entities exist and are managed within an organization
• Users can belong to multiple organizations. If you belong to multiple organizations, when you visit your user profile you will see an option to switch your active organization.

Projects

• Projects are a way to organize related groups of configs together. They can be analogous to a product or application, to a product team, or however you'd like to use them.
• Configs belong to projects
• Each project defines an arbitrary number of environments. By default, the Test and Production environments are created automatically.
• An organization can have many projects. Depending on your billing plan, there may be a limit on how many projects you can create.

Environments

• Each project can have an arbitrary number of environments. However, we recommend to match the environments in your ConfigDirector project to the deployable environments for your application. The Test and Production environments are created automatically for each project.
• Targeting rules for configs exist within an environment
• Client and server SDK keys belong to an environment. This means your application will need to configure the corresponding SDK key for each environment it is deployed to. Usually, this means providing the SDK keys via environment variables in your application.
• When you provide a user context via an SDK, that user context will exist within that environment (the environment the SDK key belongs to).

Configs

• Configs are an individual instance of a configuration value, feature flag, kill switch, or experiment.
• Configs belong to projects, and each project can have an arbitrary number of configs. Depending on your billing plan, there may be a limit on the number of configs per project.
• The value returned by a config for any given environment is defined via targeting rules.

Targeting Rules

• Each config, has a set of targeting rules for each environment defined in that project
• All targeting rules have a default value for each environment
• Targeting rules can have many rules with one or multiple conditions in each rule, as well as many percentage based rollouts.

User Contexts

• User contexts are provided via the SDKs and belong to the environment that matches the SDK key being used
• User contexts may contain id, name, and traits. The traits is an arbitrary JSON object
• All of the attributes of a context may be used in targeting rules

SDK Keys

• SDK keys belong to and identify an environment within a project when using any of our SDKs
• There are client and server SDK keys. The documentation for each SDK will note which key should be used.
• Each environment can have up to five client SDK keys and five server SDK keys
• Server SDK keys are considered a secret. Server SDKs download the targeting rules in order to be able to evaluate targeting rules for any user context in memory without needing to reach ConfigDirector servers over the network for each evaluation.
• Since targeting rules may contain private or proprietary information, the server SDK key should be treated as a sensitive password
• Client SDK keys are not considered sensitive. This is because client SDKs only receive the final evaluated values.