Security & governance

Governance for configuration changes

With governance turned on, creating or deleting an object and creating, editing or deleting a field stop taking effect right away: they become requests a manager has to approve. The queue lives in Settings, Pending configuration changes, and you can also require that whoever asks for a change is not the one who approves it.

In an organization where several people touch the configuration, the usual damage is not malice: it is someone deleting a field another team was using, making a field required overnight, or creating a duplicate object because they did not notice one already existed. Change governance puts a second pair of eyes in front of any of those five operations.

Turning governance on

Open Settings and click Organization.
Find Require approval for configuration changes and turn the switch on.
The label changes to show Approval required (on).

While the switch is off, and it starts off, everything keeps being applied immediately, exactly as before.

What exactly goes through the queue

Create object.
Delete object.
Create field.
Edit field.
Delete field.

Only those five operations. Pipelines, automations, roles and permissions, email templates, integrations or any other setting keep taking effect immediately, even with governance on. That matters, so nobody is left with the false impression that the whole configuration is under review. Two of them are deliberately left out: a pipeline and an automation are saved whole, so a request approved days later would restore an old structure over what changed in the meantime; and an integration would carry its credential into the request.

How a request works

The person performs the operation as usual, for example creating a field in Settings, Objects.
Instead of applying it, the system records a pending request and notifies every manager in the organization through the bell.
A manager opens Settings, Pending configuration changes and sees the request on the Pending tab, with Type, Change, Requested by, Requested at and Status.
They click Approve, and only at that moment is the change really applied, or Reject, and nothing happens.
Whoever made the request gets a notification with the outcome.

The History tab shows requests that have already been decided, with the status Approved or Rejected.

Example: At a logistics operator, an analyst tries to delete the Manifest code field on the Delivery object. With governance on, the field is still there and a request appears in the queue. The manager realizes two reports use that field, clicks Reject, and the analyst is notified. The data was never at risk.

Who can do what

Turning governance on and off requires permission to manage settings.
Approving and rejecting requires permission to manage settings. Anyone else gets the message Only managers can approve or reject.
The queue and the history can be viewed by anyone with access to the screen, even without the power to decide.

💡 By default the same person can request and approve their own change, as long as they have manager permission. If you need real separation, turn on Whoever requests a change cannot approve it, right below the governance switch: from then on the system refuses the decision and asks for another manager. It is opt-in for a reason: in an organization with a single manager it would leave the configuration frozen, because nobody else could approve. The queue now shows who requested each change, and the history shows who decided it.

Common questions

Does turning governance off approve what is pending? No. The requests stay put until someone decides.
Does rejecting delete anything? No. Rejecting only marks the request as rejected; nothing is applied.
Does approving a field deletion erase the data? It carries out the field deletion that was requested, with the same effects as doing it directly. Treat an approved deletion as final.

Open this article inside the system →