> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/issueops/issueops/developer-config.md).

# Developer config

The developer config is a per-project policy that defines the Salesforce access codev grants when it creates a user. It holds a set of named **access levels**, each mapping to a Salesforce profile and the permission sets, groups, and licenses assigned on top of it.

Requests name a level rather than individual permissions. codev resolves the profile and assignments from the stored policy, so a request cannot carry its own permissions, and a request that names a level with no stored policy fails with that reason.

One policy is stored per project. Project members can read it; only **owners** can change it. It is under **Ops → Developer Config**.

## Access levels

<figure><img src="/files/tlAFw1DY6cXVnduQHxuM" alt="The Developer Config page showing two access levels"><figcaption><p>Access levels on the left, the selected level's profile and assignments on the right</p></figcaption></figure>

An access level is a name you choose, bound to these fields:

| Field                       | What it does                                                                                                                             |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| **Profile**                 | The Salesforce profile the user is created with. Exactly one, required.                                                                  |
| **Permission sets**         | Assigned after the profile.                                                                                                              |
| **Permission set groups**   | Assigned after the individual permission sets.                                                                                           |
| **Permission set licenses** | Licenses granted alongside the assignments.                                                                                              |
| **Settings**                | Boolean user permissions set on the user record, such as `UserPermissionsMarketingUser`. Editable in YAML only; the form preserves them. |

Select a level in the **Access levels** rail to edit it; **+** adds one. Each of the four assignment fields suggests names from the repository's metadata on the default branch and from a connected org, and accepts a typed value when the name is in neither.

One level carries the **Default** badge. codev uses it when a request does not name a level.

## Creating a policy

<figure><img src="/files/wI8Aiik1TVLhBWDnWZ4p" alt="Developer Config with no policy stored"><figcaption><p>Until a policy is stored, provisioning is blocked and the page offers to create one</p></figcaption></figure>

A project starts with no policy, and provisioning is blocked until one exists. **Create developer config** opens the editor.

<figure><img src="/files/i77HAvf7NHeS3eaU7WNI" alt="The create developer config dialog"><figcaption><p>Name the levels and pick a profile and assignments for each, then save</p></figcaption></figure>

Name the levels, give each a profile and its assignments, mark one as the default, then **Save developer config**. The policy is validated against its schema on save; a level without a profile, or a name with unsupported characters, is rejected with the reason.

## Importing from the repository

<figure><img src="/files/0rc7UEfBsuFhVaq0HxdS" alt="The developer config actions menu"><figcaption><p>The actions menu switches to raw YAML or seeds the policy from the repository</p></figcaption></figure>

**Import from repo** reads a developer config committed to the repository's default branch and stores it as the project's policy.

Import seeds the stored policy once. Afterwards codev reads the stored copy, and changes to the repository file take effect only on a further import.

**Edit as YAML** in the same menu opens the raw document. The form and the YAML are two views of the same policy, and both are validated on save.

## Saving and deleting

Each save increments the policy's version. A save that carries an older version is rejected and reports the current one, so a concurrent edit is not overwritten — reload the page, re-apply the change, and save.

**Delete** removes the stored policy. Provisioning is blocked again until a policy exists.

## Where the policy is used

Two flows provision Salesforce access from the policy.

**Adding users to an environment you hold** — the **Add users** action on a dev sandbox takes a list of people, each with its own access level and password-reset choice.

<figure><img src="/files/CdRiCL5yZxw7cXQd9lW8" alt="The Add users dialog with a per-user access level"><figcaption><p>Each person gets their own access level and password-reset choice</p></figcaption></figure>

**Requesting elevated privileges** — a privileged-access request from the [Operations catalogue](/flxbl/codev/issueops/issueops.md#the-operations-catalogue) names a level, and the approved request grants what that level defines.

<figure><img src="/files/NLdXoPDTCV0W2Q7OCuKM" alt="The elevated privileges request form with an access level"><figcaption><p>A privileged-access request names an access level from the stored policy</p></figcaption></figure>

## Who can change it

| Action                                | Role   |
| ------------------------------------- | ------ |
| Read the policy and its access levels | Member |
| Create, edit, import, delete          | Owner  |

Every change is recorded in the [audit log](/flxbl/codev/governance/audit.md).

## Related

{% content-ref url="/pages/iyYdqORodpg8Xec0NhcL" %}
[IssueOps](/flxbl/codev/issueops/issueops.md)
{% endcontent-ref %}

{% content-ref url="/pages/Pa1TYkeFP4tblZZDut0O" %}
[Fetching and Using Environments](/flxbl/codev/pools/using-pools.md)
{% endcontent-ref %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/codev/issueops/issueops/developer-config.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.