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
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
A project starts with no policy, and provisioning is blocked until one exists. Create developer config opens the editor.
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
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.
Requesting elevated privileges — a privileged-access request from the Operations catalogue names a level, and the approved request grants what that level defines.
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.