Field-level permissions explained for small teams

Field-level permissions control single fields inside a record, such as a customer's credit limit or bank details, on top of the record access a role gives. Each field gets its own Read and Update switch, so a colleague can work with a customer without seeing or changing every number.

Many small teams start with "everyone sees everything" and that is fine, until the day a new hire, a freelancer or an accountant joins. Field-level permissions let you keep that easy default and close the few doors that matter.

Roles, records and fields: three layers

Access control in business software usually works in layers. Each one answers a narrower question than the one above it.

Layer	Question it answers	Example
Role	What kind of person is this?	An admin, a salesperson, a project lead
Record access	Which kinds of records can they create, read, update or delete?	Customers yes, company settings no
Field access	Inside a record, which details can they see, and which can they change?	Sees a customer's credit limit, can't change it

Record access alone is often too blunt. If a salesperson needs to update a customer's address, a record-level rule gives them the whole customer, including terms and limits that finance owns. Field access is the scalpel: same record, different rights per detail.

Which fields deserve their own rule

Not many. In a small team, a field-level rule is worth it when a wrong edit costs money or when the detail is personal. Typical candidates:

• Credit limits and payment terms. They decide how much risk you take on a customer.
• Bank details. A changed account number on a supplier is a classic fraud route.
• Costs and margins. Purchase prices and internal rates that shouldn't travel to customers.
• Personal data. Private phone numbers or notes about people.

Everything else can stay open. Each extra rule is one more thing to explain when someone asks why they can't see a field.

How it works in Swiftly Workspace

Admins manage roles under Administration, then Roles, on Mac, iPhone and iPad. A few things are set up for you, and the rest is a matter of switches.

• New members get the Standard role. Standard gives full access to the business data (customers, documents, payments, projects, timesheets) but no administration of members, roles or company-wide settings such as modules and security. Our guide to the Standard role explains why that default suits many small teams.
• Admin sees and changes everything. Its permission grid is locked, with a note that the Admin role has implicit full access.
• Member starts with nothing. It is an empty role: someone who holds just this role sees no data until an admin grants it.
• Ready-made roles show the idea. The Sales role, for instance, can read a customer's credit limit but cannot change it.
• Your own roles. Click Add Role (the + button), give the role a name and description on the General tab and create it. The Permissions tab opens once the role exists.

On the Permissions tab you pick an object, such as customers or items. At the top is a row of Create, Read, Update and Delete switches for all its records. Below it, every field has its own Read and Update switch, and sensitive fields are marked. Each switch saves as you flip it, and Grant All turns everything on when you want to start open and remove a few rights.

What a person then sees follows from those switches. A field without Read is left out of what the server sends to their app, so it simply isn't on their screen. A field with Read but without Update is shown grayed out, so they can look but not edit.

Permissions add up

A member can hold more than one role, and an admin can also grant a single person extra rights directly. Everything they hold is added together: a second role or a direct grant can give more access, never less. On a Mac, the member's own window shows their roles and their direct permissions on separate tabs.

Keep the company's own field choices apart from this. Hiding a field you don't use for the whole company is a separate setting, explained in choosing which fields your forms show. A field appears for a person when the company uses it and their permissions allow it.

A sensible starting point

1. Leave new colleagues on Standard unless you have a reason not to.
2. List the two or three fields that would hurt if the wrong person changed them.
3. Create one custom role for the people who should see those fields but not change them, and switch off Update on exactly those fields.
4. Keep Admin for the people who run the company's settings. Larger teams often also move sign-in itself to an identity provider; how single sign-on works covers that side.
5. Review roles when someone joins or leaves. Our walkthrough of inviting your team on a Mac covers the joining side.

Permissions decide who can change what; a record's history shows who did. Read more about change history on every record.

Frequently asked questions

What is the difference between role-based and field-level permissions?

Role-based permissions decide which kinds of records a person can create, read, update or delete. Field-level permissions work inside a record and decide, field by field, what that person can see and change. Many teams use both: roles for the broad picture, field rules for a handful of sensitive details.

Can one person have more than one role?

In many systems, yes. In Swiftly Workspace a member can hold several roles, and their rights are the sum of all of them plus any rights granted to them directly.

What does someone see when they can't read a field?

Nothing: the field is left out of their screen rather than shown blank or masked. If they can read it but not update it, they see the value grayed out.

Do small teams really need custom roles?

Often not at the start. A default that opens business data to everyone, plus one admin, covers many teams of five. Add a custom role the day a field really needs protecting, not before.