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

Access levels on the left, the selected level's profile and assignments on the right

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

Until a policy is stored, provisioning is blocked and the page offers to create one

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

Name the levels and pick a profile and assignments for each, then save

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

The actions menu switches to raw YAML or seeds the policy from the repository

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.

Each person gets their own access level and password-reset choice

Requesting elevated privileges — a privileged-access request from the Operations catalogue names a level, and the approved request grants what that level defines.

A privileged-access request names an access level from the stored policy

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.

Related

IssueOpsFetching and Using Environments