Members & roles

Sheetward uses two layers of roles, so you decide who runs the workspace and — separately — who can use each app. A workspace role — Admin, Builder or Member — is chosen when you invite someone and covers the whole workspace. An App role — Owner, Editor or Viewer — covers a single app. The two are independent: set workspace roles in the Admin console → Users, and app roles on each app's Members tab.

Invite someone to the workspace

Open the Admin console → Users (admins only).
Enter the person's email address.
Choose their workspace role — Admin, Builder or Member.
Send the invitation.
They follow the emailed link to set a password and join your workspace.

Workspace roles

Role	Can do
Admin	Run the workspace: manage who has access, monitor usage, look after the subscription plan and billing, and run housekeeping — all from the Admin console, which only admins can open. Admins can also create and manage every app in the workspace.
Builder	Everything a member can do, plus create and manage apps. A builder automatically becomes the Owner of any app they create. Builders can't delete apps — that stays with admins.
Member	Use the apps an App Owner shares with them, with whatever app role they're given — Owner, Editor or Viewer.

App roles — the app's Owner grants these per app, on the app's Members tab:

Role	Can do
Owner	Everything: edit data, manage the app's members, change the app itself, publish, and archive.
Editor	Add and edit records — say, entering expense claims — and import and export data.
Viewer	Read-only: view records and export them.

The workspace Owner. The person who signs up for a workspace becomes its Owner — a special admin, and the single point of contact for the workspace. Every admin, the owner included, is automatically the App Owner of every app in the workspace.

Builders own what they build. A builder becomes the App Owner of every app they create, and another owner can grant them a role on other apps. Builders aren't admins, though: they can't open the Admin console, and deleting or copying apps stays with admins. If a builder reaches the plan's app limit, they're asked to contact a workspace admin — only admins can change the plan. Plans also limit how many admins, builders and members a workspace can have, so an invite is refused once a role's seats are full.

One workspace per admin — usually. You're normally an admin of only one workspace, but you can be a member of many. On a plan with multiple workspaces enabled, an owner can create extra workspaces from the sign-up page — say, one per business unit. They can also be invited as an admin into another such workspace. Otherwise, inviting someone who already runs a workspace as an admin is declined — invite them as a member instead. Workspace names are unique across Sheetward, so a new workspace may need a different name.

Sensitive data stays covered. SSN and credit-card fields appear masked to the last 4 digits in the grid and on forms, with a reveal toggle while editing. You can give any field the same treatment with a sensitive rule. Card numbers go further: only the last 4 digits are ever stored. Exports mask these fields by default; an owner can tick Include sensitive data to export the real values.

Reset a member's password. A workspace admin can help someone who is locked out: on Admin console → Users, click Reset password. This creates a single-use link, valid for 1 hour, that the member follows to choose a new password — the admin never sees or sets it.

Member lockout. Need quiet time for maintenance or a stocktake? From Admin console → Users → Member access, an admin can temporarily lock the workspace for member- and builder-role users. Add a message they see when they try to sign in, and an optional auto-lift duration — or keep it locked until lifted. Admins and the owner keep access, so the lockout can always be lifted.

Deactivate or remove a user. When someone leaves the team, an admin has two options on Admin console → Users. Deactivate blocks their sign-in everywhere; Reactivate restores it. Remove drops their access to this workspace only — their account and any other workspaces are untouched. You can't do either to yourself or to the workspace owner. Deactivation only applies to an account that belongs to this workspace alone — for someone in several workspaces, remove them from this one instead.

Action	What happens	Best for
Deactivate	Blocks the person's sign-in everywhere; Reactivate restores it.	Someone whose account belongs to this workspace alone.
Remove	Drops their access to this workspace only — their account and any other workspaces are untouched.	Someone who belongs to several workspaces.

Restrict record visibility. When editors should see only their own work — say, each salesperson's own expense claims — an app owner can switch this on from the app's Members page. Owners keep seeing every record; each editor sees only the records they created — in the record list, search, exports, and dashboards alike. Even the record count on the app tile matches what each person actually sees. The viewer role is unavailable while this is on. The switch refuses to turn on until any existing viewers are re-roled or removed — it never removes anyone itself. It also refuses while the app is published to the web — a public reader is an anonymous viewer — so unpublish first. Published standalone apps keep the restriction. It also switches on automatically — and stays on — while the app's approval workflow is enabled.

Approval workflow. When records need a sign-off — an expense claim, a purchase order — an app owner can switch the workflow on from the Members page. Turning it on requires assigning both an Approver and an Alternate approver from the app's members, and it also switches on Restrict record visibility. Records then move draft → submitted → approved or rejected. The creator submits, and can withdraw before anyone acts. Either approver can approve or reject — never their own submission, which is exactly why there are two approvers. A submitted or approved record is read-only for everyone, so no signed-off record changes silently. It stays that way until it is withdrawn, rejected, or reopened by the owner or its creator. Approvers find waiting records in a For your approval section above the record list. Rejecting requires a note explaining the decision (optional when approving); the note shows on the record and in its History. Deleting is deliberate too: owners can delete draft or rejected records, while editors can delete only records they created, and only while they're drafts. A status chip shows each record's state, and the inbox icon shows a red dot when something awaits you. The people involved are notified in Messages. Published standalone apps keep the whole flow (without email).

State	What it means	Who can act
Draft	Being written — no one has been asked to sign off yet.	The creator edits, submits, or deletes it; the owner can delete it too.
Submitted	Waiting for a decision — the record is read-only.	Either approver approves or rejects (never their own submission); the creator can withdraw it before anyone acts.
Approved	Signed off — the record stays read-only so nothing changes silently.	The owner or the creator can reopen it for changes.
Rejected	Sent back with a note explaining the decision.	The creator fixes and resubmits it; the owner can delete it.

PreviousMulti-language support NextPublish an app to the web

Sheetward User Guide

Members & roles