--- title: How to set who can do what url: https://tideswell.xyz/docs/workspace-admin/permissions description: Every action has a minimum role. Set each one to admin, lead or member, and changes apply immediately. --- > Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further. # How to set who can do what **Settings › Permissions** is one row per action, with three buttons: **admin**, **lead**, **member**. You are setting the **lowest** rank allowed to do that thing. ## How does it work? [#how-does-it-work] Click the rank you want and it saves immediately. There is no Save button, and the page says changes apply straight away. * **member** means everybody can. * **lead** means anybody who leads at least one department, plus admins. * **admin** means admins only, plus the workspace owner. ## What is in the list? [#what-is-in-the-list] Around forty-five built-in actions, plus four dials for every Object. Built-in ones read as sentences: "Rename organization", "Invite members", "Create projects", "Create channels", "Define Objects", "Configure modules", "View Mission Control". The per-Object rows are written in your own words, so you see "Suppliers · View", "Purchase Orders · Update", "Repairs · Update". Those four dials are View, Create, Update and Archive, per . ## Which rows are worth changing? [#which-rows-are-worth-changing] The ones people ask about, and they are usually the same three. **Create projects** at lead is the default and often wants to be member in a small team. **Approve purchase orders** decides who can sign off spending, and it is worth setting deliberately rather than leaving it. Remember that nobody can approve their own request whatever this row says, per . **View** rows on sensitive record types, when part of the business should not see supplier pricing or customer records. Leave the rest alone until something is actually wrong. The defaults were chosen to work. ## Why did loosening a row not let somebody into Settings? [#why-did-loosening-a-row-not-let-somebody-into-settings] Because **the whole Settings area is gated on being an admin, separately**. Setting "Create departments" to lead lets a lead create a department through other surfaces, and never through **Settings › Departments**. That screen needs admin regardless of the row. This is the single most confusing thing on this page. If somebody needs to work in Settings, they need to be an admin; a permission row will not do it. ## Why can I not change the permissions row itself? [#why-can-i-not-change-the-permissions-row-itself] Because "Edit these permissions" is permanently locked to admin. The member and lead buttons are unavailable with a tooltip explaining it is locked to prevent lockout. That is the safety catch that stops a workspace from being permanently locked out of its own settings. ## What happens to a row nobody has configured? [#what-happens-to-a-row-nobody-has-configured] It denies. Tideswell fails closed, so an unknown or unconfigured action is refused rather than allowed. That is why a brand-new capability never quietly becomes available to everybody. ## Why is there a row marked archived? [#why-is-there-a-row-marked-archived] Because archiving a custom Object leaves its four permission rows in place, marked archived, so that restoring the Object restores the access it had. Those rows do nothing while the Object is archived. See . ## How do you work out why somebody cannot do something? [#how-do-you-work-out-why-somebody-cannot-do-something] Do not start here. Start with , which walks the three layers in order: the module, the permission, and the department the record belongs to. Most reports that look like a permission problem are department scope: the person holds the right in one team and not in the one the record lives in. Changing a row here would not fix that. is the step-by-step version.