Docs
Core concepts

How to work out who can do what in your workspace

Work out what a person can see and do in Tideswell, and tell a switched-off module apart from a permission they have not been given.

Somebody in your Tideswell workspace says a screen has vanished, or a button they used yesterday is gone. Three separate things decide what a person can see in Tideswell, and each has its own fix on its own admin screen: Settings › Modules, Settings › Members and Settings › Permissions. This page is the order to check them in, written so you can do most of it from what you can already see without waiting on an admin.

The third of those screens carries one row for every kind of record in your workspace, including each Object your team has defined. If that word is new, What is an Object? introduces them; you can follow this page without reading it first.

Before you start

The screens named here (Settings › Permissions, Settings › Modules, Settings › Members) are admin-only. If you cannot see Settings in the sidebar footer, you are not an admin of this workspace. The diagnosis in the middle of this page is the part meant for you, and it needs nothing but the sidebar and a colleague willing to look at their own screen.

What decides what a person can see?

Three layers stack, and all three have to allow something before it appears. Modules decide which areas exist for the whole workspace.

Your role (member, lead or admin) decides which actions you may take. A set of dials on each kind of record, built in or an Object of your own, decides which of them you may view, create, update or archive.

Read them in that order, because a lower layer cannot rescue a higher one. Say the Purchase orders module is switched off at Fairgreen Golf Co. It does not matter that Priya is an admin with every dial open: there is no purchasing area for her to open, and a saved bookmark to it reports that the page does not exist.

A fourth thing sits alongside rather than above: departments. Being in one gives you that team's task view and its channels. Leading one raises your role, which is the part people miss.

One house rule shapes the whole search: hidden rather than locked. Tideswell leaves out what you cannot use instead of showing you a greyed-out version of it.

Settings does not appear for a non-admin, and an Object you cannot view is not in the sidebar. A few screens, such as approvals and decisions, show a short "ask an admin" message instead, because you may have arrived from a link somebody sent you.

How does somebody become a lead?

There are three roles but only two of them are set on a person. In Settings › Members you make somebody a Member or an Admin. Lead is the third role and it is earned: turn on the Lead switch for at least one department, and that person is a lead from then on.

This surprises every new admin, because they go looking for a "Lead" option in the role dropdown and do not find one. The sequence is:

  1. Open Settings › Members and find the person.
  2. Open their Departments dropdown.
  3. Tick the department they belong to and turn on the Lead switch for it.
  4. Press Apply for that department.

The switch and the department travel together, so submit a row with Lead switched off only when you mean to step somebody down from leading that team.

Lead sits between member and admin, and plenty of actions start there. That is the point: at Fairgreen Golf Co. you can let whoever leads Production approve purchase orders without handing them the whole Settings area.

Work out whether it is switched off or not allowed

Do this in order and you will usually know within two minutes. The first step is the one that splits the two causes apart, so do not skip it.

  1. Ask one colleague to look for the same thing. If nobody in the workspace can see it, a module is switched off. If some people can see it and others cannot, it is permissions.
  2. Open the address directly, from a bookmark or a link somebody sends you. A switched-off area reports that the page does not exist, even from a bookmark that worked last month. A permission you do not hold either hides the section entirely or, on a few screens, names what you need and tells you to ask an admin.
  3. Check the person's role in Settings › Members. Member or Admin, and remember that the whole Settings area needs Admin regardless of anything else.
  4. Check whether they need to be a lead, and if so whether the Lead switch is on for a department. A great many actions start at lead.
  5. If it is one kind of record, check that record's own dials in Settings › Permissions. Someone can open the store dashboard and still be refused the supplier list, because those are separate dials.
  6. If it is a Settings screen, the answer is always the Admin role.

One quirk to expect: a change to somebody's role or departments can take up to a minute to show up in their sidebar. The check that actually matters runs on every action, so the delay is cosmetic. A reload settles it.

If all three layers look right and the answer is still no, check these three:

  • The kind of record, not the area. Store access and supplier access are different dials, as are decisions, orders, customers and stock. The refusal on screen names the specific thing that was withheld, which tells you which row to open.
  • Which workspace they are in. Everything belongs to exactly one workspace, and a person can belong to more than one. Tideswell glossary defines the term.
  • Where they are looking. How to find and open your records covers where records live in the sidebar and how they are grouped.

Change what a role is allowed to do

Open Settings › Permissions. Every action in the workspace is a row with three radio buttons, admin, lead and member, and you set the lowest role allowed to do it. Changes save the moment you click, and the page says so: there is no Save button to press afterwards.

Rows come in two shapes. Workspace actions read as plain sentences, such as "Invite members", "Create projects", "Create channels" or "Configure modules". Rows for a kind of record read in your own words with the action after them, for example "Suppliers · View", "Repairs · Create" or "Purchase Orders · Update".

Each kind of record carries up to four dials: View, Create, Update and Archive. An Object you create starts with the first three open to every member and archiving held at lead.

That is usually the right shape: everyone logs a repair, only a lead retires one. Who can see and edit an Object covers those dials in full, including how they read for an Object you have archived.

One row behaves differently on purpose: the row governing permissions themselves stays at admin, with its lower buttons disabled and a tooltip explaining that this is what keeps a workspace from locking itself out.

Why does opening a row not let a lead into Settings?

Because the Settings area is gated on the Admin role separately, before any row on the permissions matrix is consulted. Setting "Create departments" to lead lets a lead create a department wherever else that action is offered. It does not put Settings › Departments in front of them.

Say this one plainly to your team: Settings is admins only. Everything under it, members, permissions, departments, sub-task types, modules, stages, integrations, the audit log and Settings › Objects, follows the same rule.

To let somebody build or change an Object, give them the Admin role rather than a loosened dial. See Decide between a built-in record and your own Object for what building one involves.

Ownership catches people the same way. Being the owner of a record makes you accountable for it and grants you nothing, so do not use ownership to hand somebody access. See How to move a record through its stages and set an owner.

Hand your authority to someone while you are away

Open your account settings from the avatar menu at the bottom of the sidebar, find the out of office card, pick a colleague and pick the date it should stop. Press Save and the card reads back what you have done: "Dana can act with your standing until 18 August". Press Clear to end it early.

Be clear with yourself about what you are handing over. For the period you set, that person can do anything your role covers, not only approve things: managing other people's accounts, changing connected tools, all of it. It stops on its own on the date you chose, within the next ninety days, and it never lowers anybody, so a colleague with more authority than you keeps theirs.

It also does not chain: if Priya covers for Dana and Dana covers for Sam, Sam gets Dana's own standing and never Priya's. The person actually away keeps getting their notifications, so nothing goes quiet while you are on a plane.

One last case looks exactly like a permission problem and is not. An Object that has been archived disappears from the sidebar and from the new-record menu for everybody, while its permission rows stay in place marked as archived. See Rename, reorder or retire an Object.

On this page