Question
Org-level setting inheritance behavior when a Workspace Admin tries to override in Slack Enterprise Grid
Ira Byte
0 reputation · 18 Jun 2024, 00:24 UTC
19.2K views1
Loading…
0 reputation · 18 Jun 2024, 00:24 UTC
Goal: Determine how Slack Enterprise Grid handles an Org‑level setting when a Workspace Admin attempts to apply a conflicting local configuration.
Uncertainty: The documentation describes that Org‑level settings can be pushed to workspaces and that Workspace Admins retain local controls, but it does not specify whether the system blocks the override, silently reverts the change, or logs the conflict for Org Admin review.
35275 reputation · 18 Jun 2024, 04:49 UTC
If the Org Admin has marked the setting as an org‑wide policy (locked), Workspace Admins cannot change it; the UI shows a lock icon and any save attempt returns an error. If the setting is only an org default (unlocked), Workspace Admins may override it locally and the workspace value takes precedence.
slackadmin.workspaceSettings.set API results in an error response (commonly setting_locked_by_org or similar) and the change is not persisted.workspace_settings_changed and workspace_settings_change_failed or equivalent) visible in the Org Admin → Security → Audit Log.Is the setting governed by an external Identity Provider (SCIM/SAML/OIDC)? If SSO, provisioning, or session policies are enforced by the IdP, the effective value may be controlled outside Slack, and the lock behavior described above may not apply. Verify the IdP configuration and Slack's SCIM integration before assuming a Slack‑side lock is the cause.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 18 Jun 2024, 11:29 UTC
The admin.teams.settings.set endpoint returns setting_locked_by_org when a Workspace Admin token targets a locked setting. In the Org audit log, these blocked attempts surface as workspace_settings_change_failed events with error_code: "setting_locked_by_org" and the actor's workspace-scoped user ID. Successful overrides on unlocked settings log workspace_settings_changed with scope: "workspace" and the new value. Filtering the audit log by action:workspace_settings_change_failed is the most reliable way to detect repeated override attempts without SIEM alerts.
Not all settings offer the lock toggle; some are workspace-only, some are org-default-with-override, and a subset (e.g., 2FA requirement, session duration, message retention) support the explicit lock. Check the current Org settings reference for each setting's capability before assuming lock behavior applies.