How to set who can see and edit an Object

An Object is a kind of record your team defines, such as Repairs or Sample requests, and every Object carries its own settings for who can do what with it. Objects are built in Settings › Objects, which What is an Object? introduces. Who can see and edit them is set on Settings › Permissions, and this page is how you set it.

Your repairs can be open to everyone while your fabric trials are held to leads, and neither decision affects the other. Creating an Object sets these up for you, so you only come here when the defaults are not what you want.

Before you start

Settings › Permissions is open to admins only. How to work out who can do what in your workspace is the wider explanation of how a person's role turns into what appears on their screen.

There are three roles. An admin sets a person to member or admin in the Role menu on Settings › Members. Someone becomes a lead when an admin turns on the Lead switch beside one of their departments on the same screen and presses Apply.

Where do you set who can do what?

On Settings › Permissions. Each row is one action, with three columns across it: admin, lead and member. Pick the lowest role allowed to do that thing.

Choosing member means everyone, choosing lead means leads and admins, and choosing admin means admins only. Each change saves the moment you click it, as the page says: "Changes apply immediately."

Your own Objects are listed by their plural name. A Repairs Object at Fairgreen Golf Co. gives you four rows: Repairs · View, Repairs · Create, Repairs · Update and Repairs · Archive.

What do the four rows control?

Each one covers a different thing a person can do with the Object's records, and you set them independently.

• View decides who sees the Object at all: its row in the Objects area of the menu, its list and every record in it. Someone below this role has no menu row, and a link to the list opens a page reading "Repairs access required" with "Ask an admin to grant you access to Repairs."
• Create decides who sees the New Repair button on the Object's list, and so who can add a record.
• Update decides who can change a record's fields, move it through the statuses set up in How to set up the stages a record moves through, and set its owner.
• Archive decides who can take added records back out again. It applies when someone undoes a spreadsheet import into the Object, covered in How to import records from a spreadsheet, or undoes a record the Agent created from a suggestion.

A new Object opens View, Create and Update to every member, and holds Archive to leads. That suits most working Objects. Tighten View first if the Object holds anything commercially sensitive, since the other three sit behind it in practice.

Which role should each row be set to?

Start from who needs to act on the records, not from who might be curious about them. Two patterns cover most of what a brand needs.

Open to work on, careful with undo. Leave View, Create and Update on member, and keep Archive on lead. Fairgreen's Repairs Object works this way: anyone in customer service logs a repair and moves it along. Only a lead or an admin can undo an import of last season's repair log.

Visible to a few. Put View on lead when the Object holds costs, margins or supplier terms. Nobody below lead sees the menu row or the records inside it. Use it deliberately, because an Object nobody can see is an Object nobody updates.

Every row takes one of those three answers. If a setting feels like it needs to be finer than that, the information underneath it usually belongs on a separate Object with its own View row.

Decide what belongs on an Object everyone can see

Everyone who can view an Object sees every field on it. Plan the Object around that, because it is the one thing on this page that a sketch settles and a setting cannot.

In practice, that means:

• Keep a figure the whole workspace should not read on an Object with a tighter View row, rather than as one more field on an open one. Fairgreen's agreed factory prices sit on a Fabric trials Object held to leads, not on the Sample requests records the marketing team opens every day.
• Treat files the same way. A file attached to a record is visible to everyone who can open that record, so a signed contract belongs on an Object held to leads.
• Split rather than squeeze. Two linked Objects, one open and one restricted, give you a clean answer that a single wide Object cannot. How to link one Object to another covers joining them up.

How to plan your fields before you add them is the page to read before you build.

How do the built-in records work here?

They appear on the same screen, with the same three buttons, under names that say what they control. Six control viewing only: View customers, View orders, View products, View product variants, View inventory and View decisions.

Six more come as a View and Edit pair, so you can let someone read the records without letting them change any:

• View purchase orders and the buying calendar and Edit purchase orders and the buying calendar
• View suppliers and Edit suppliers
• View bills and Edit bills
• View wholesale orders and Edit wholesale orders
• View wholesale invoices and Edit wholesale invoices
• View wholesale accounts and Edit wholesale accounts

Special orders have three: View special orders, Create special orders and Edit special orders. Two more rows sit beside them: Approve purchase orders, and Record payments on special orders and write off balances.

Tasks, campaigns, members and outreach have no View row. What people can do with them is set by rows named for the action, such as Create tasks, Create and edit campaigns and cycles and Create outreach. How to set who can do what covers the rest of the screen.

How to choose between a built-in record and your own Object covers which kind to reach for when you are adding something new.

Why is something still blocked?

Five answers cover almost every case, and each names its own fix.

• Settings itself is admin only. A workspace-wide Define Objects row governs the whole of Settings › Objects. Granting it to a lead does not let them in, because everything under Settings needs the admin role as well.
• The change has not reached an open screen. A new setting applies from the next time a page is loaded. Ask anyone already looking at the record to refresh.
• A calculated field is refused when you add it. A field that reads a value across a link will not save if it would carry that value from a more restricted Object onto a more open one. The message names the role to raise your Object's View row to on this screen, or suggests reading a different field. How to build a field that works itself out has the detail.
• A change on this screen is refused. A change to a View row is refused if it would let a calculated field show values to people who cannot see the Object those values come from. The message begins "This would let people see data they aren't allowed to" and names the fields: archive those calculated fields, or change who can see the linked Object instead.
• The row says "(archived)". That Object has been archived, as in Repairs (archived) · View, and its settings are kept in case it comes back. See How to rename, reorder or retire an Object.

One row can never be lowered: Edit these permissions stays locked to admin, so a workspace cannot lock itself out. Once the rows are right, everyone else picks up at How to find and open your records.