Chapter 9
Troubleshooting
Most Buckley problems are permissions problems, and they look like nothing happening.
The rail is empty
Buckley could not read your profile list. You are missing Manage Profiles and Permission Sets. Buckley can often still read objects, which is why the workspace looks half-alive rather than broken.
A commit succeeded but nothing changed
Check the container column, not the target column. If the container is locked, the commit skipped it deliberately — that is what the lock does.
If it is a permission set group, it was never writable. The READ ONLY badge on the column header says so, and the platform rejects the write regardless of what Buckley sends.
A commit failed partway
Buckley writes in steps and tells you which one failed. The containers written before the failure keep their new values; the rest keep their old ones.
Undo restores the whole bucket to its pre-commit state, including the containers that succeeded. Run it before trying again, so you are starting from a known state rather than a mixed one.
Session or password settings did nothing
Check that the bucket actually contains profiles. Those settings do not exist on permission sets, so a bucket of permission sets applies nothing and reports no error — there was nothing to apply.
A field is missing from the matrix
Fields that cannot carry field-level security are skipped: required fields, system fields, master-detail relationships, and standard fields Salesforce locks. They are not hidden by a filter — they cannot hold FLS at all.
Changes look right but drift will not reach n of n
A locked container never counts toward drift alignment, because it is not going to receive the target. Unlock it or accept the number.
Still stuck? Note which step the commit dialog reached before it stopped — that names the metadata call that failed and is the single most useful detail for support.