Users, Permissions and Access — Admin Guide
Four Admin tabs decide who can see and change what: Users, Modules, Permissions, and Access Decisions. They work as a chain — a module has to be on, the user has to exist, their role has to carry a permission, and Access Decisions is where you find out which of those four failed when someone says "it won't let me."
For: administrators · Time: ~12 minutes · You'll need: an admin or CEO role — every tab in this guide, Permissions included.
How to access
Admin, then the tab. All four tabs, Permissions included, are open to the admin and CEO roles. If you hold one of those and Permissions is missing, that is not the gate working — it is a fault worth reporting, not something to route around by asking someone else to make the change.
How the console is organized
The tabs are grouped into sections down the left — Platform, Advanced Settings, FP&A and Accounting. The sections are gated by the modules your tenant has, so two administrators at different tenants do not see the same list. And each tab is offered only to someone the server would let read it: before showing a tab, the console asks the server whether you may open it, so a tab your role cannot use is left off your list rather than shown and refused. If somebody hands you a procedure naming a tab you do not have, it is a module difference or your own access — Modules confirms the first, and Access Decisions shows the second.
What is in each section, so you can tell a missing tab from a mis-remembered one:
| Section | Tabs |
|---|---|
| Platform | Operational Health, Users, People Import (with the Accounting module), Access Decisions, Data Sync, Configuration, Audit Log |
| Advanced Settings | System Health, Permissions, Modules, Email Recipients, Email Layout, Year Rollover, API Tokens, Setup & Repair |
| FP&A | Workable Days, Stage Probabilities, Debt Register, Covenant Scope, P&L Structure, Agency Tiers |
| Accounting | GL Mapping, Indirect Cost Pools, Exclusions, Vendors, Labor Categories, Charge Authorizations, Leave Types, Holiday Calendars, Payroll Status, Pay Periods |
The FP&A and Accounting sections disappear entirely on a tenant without those modules — which is why the list above is what your console can show, not what it does.
Inside FP&A and Accounting, the rarely-changed screens sit behind an "Advanced settings" disclosure at the bottom of the section, closed until you open it. The number beside it says how many tabs are inside, and the section remembers your choice. These are the settings whose reach goes far beyond their own screen — a wrong value re-states every rate, misfiles every posting, or changes whether a covenant reads as passing — so they no longer sit at the same visual rank as the everyday tabs. Nothing moved between sections. From the table above: FP&A → Debt Register, Covenant Scope, P&L Structure; Accounting → GL Mapping, Indirect Cost Pools, Exclusions, Leave Types, Pay Periods. The tab you are on is always shown, even with the disclosure closed, and hovering a tab in the tail says why it lives there.
Sending somebody a link to a specific tab
Link with ?tab=, never with a path. The console reads which tab to
open from the query string, so /admin?tab=users works and /admin/users does
not — the second one still loads the console, raises no error, and quietly drops
the recipient on the default tab. Nothing tells them they landed somewhere else,
which is exactly why it is worth getting right when you paste a link into a
ticket.
The simplest way to get a correct link is to open the tab yourself and copy the address bar.
Part 1 — The chain, and why it matters for troubleshooting
Access is not one setting. Four things must all be true before a person can do something:
- The module is enabled for the tenant → Modules
- The user exists and is active → Users
- Their role carries the permission for that area → Permissions
- Nothing else refuses it at the moment they try
When someone reports "it won't let me", work that order. Most reports resolve at step 1 or 3, and checking them in order is faster than guessing — a disabled module and a missing permission look identical from the user's seat.
Part 2 — Users
The tab is headed User Management, and New User is the form that adds one. The table carries each person's Last Login, which is the fastest way to tell an account nobody uses from one somebody cannot get into.
To add many people at once, or a new hire who also needs an employee record, use People Import in the Platform section instead of New User: one workbook creates the employee record and the login together, through the same rules this tab applies, and refuses a file that would create a duplicate. See People Import.
Contact is how to reach this person: their email on the first line and their work phone under it. The email is load-bearing — it is how the account finds its timesheet, so a wrong one lets somebody sign in and record no hours. Work phone is not: nothing in Arcvue depends on it, and a blank one is an ordinary state rather than a gap.
Fill the phone in when the person is somebody your contracts team names as a point of contact on an agreement. Contract Requests offers your own people where a document names your side's contact, and it fills their title, email and phone from this row — so a number entered once here stops being re-keyed on every request. Leave it blank and they are still offered, just without a phone.
Title is the person's job title. Arcvue can suggest one from their role, and Job title override is where you type your own instead — the override is what you reach for when the suggestion is close but wrong, rather than editing the role.
Limit which contracts this user can see opens the contract-scope panel; Close contract access without saving leaves it without changing anything. Cancel on an inline edit does the same for that row.
Subcontractor portal seats are counted separately from your own users, because a subcontractor's people reach a different surface.
Create and maintain the people. Each user carries a Display Name and a role; roles reflect how the firm is actually organized — for example Division Lead, Functional Lead, Director of Contracts.
Three recovery actions live here:
- Resend invitation — for someone who has never signed in and says their invitation never came. It emails a new one-time password, and the one in any earlier invitation stops working. It is offered only until their first sign-in; after that, use Reset password. Under Never in the Last login column, the row says whether their newest invitation was sent -- hover over it for the reason when it was not.
- Reset password — set a new one. Minimum 8 characters, enforced. It also clears a lockout from failed sign-in attempts, so it is how you let back in someone who has locked themselves out.
- Reset MFA — clears their second factor so they can enroll again. This is what you use when someone has lost their device, and it is the action to be deliberate about: it lowers that account's protection until they re-enroll.
Deactivate, at the end of the row, is for someone who has left. After you confirm, they are signed out everywhere at once, on the web and on their phone, and every sign-in after that is refused. The row's status reads Inactive. There is no delete: an account that posted entries or approved a timecard has to stay attributable, so their history stays. Restore access, in the same place on an inactive row, lets them sign in again with their existing password and authenticator.
Every one of these — creating a user, changing a role, resetting a password, clearing MFA, unlocking an account, deactivating or restoring someone — is written to the Audit Log in the same transaction as the change, so the trail cannot claim something that rolled back and a change cannot land unrecorded.
Invitations from payroll
Turn on Invite New Hires from Payroll (Admin > Config) and Arcvue watches the payroll roster for you. The morning after someone is added to payroll, they get an Employee login and an email invitation with their username and a one-time password. Their login is tied to their payroll record, so a later change to their email on payroll does not cut them off from their timesheet.
- Only people added after you switch it on are invited. Everyone already on the roster stays as they are -- including anyone you have deliberately not given a login. Switching it off and on again starts over from that moment.
- Someone who already has a login is not invited again when the login's email matches payroll: Arcvue ties that login to their payroll record instead.
- Records without a real email address are skipped. Invite that person from Users once payroll has their address.
- If an invitation never arrives, check the email on their login in Users, correct it if it is wrong, then use Resend invitation on their row.
- An unusually large batch is held, not sent. If one morning's roster would invite more than 15 people, nobody is invited that day and Arcvue support is alerted. That is usually a payroll feed problem; invite from Users once it is resolved.
Switching off former employees
Turn on Switch Off Former Employees' Logins (Admin > Config) and Arcvue switches off the login of anyone who has left payroll once a few days have passed since their termination date -- three by default, set by Days Before a Former Employee's Login Is Switched Off -- so they can still enter their final timesheet.
- It acts once per departure. If you switch someone back on in Users, they stay on; only a new termination on payroll switches them off again.
- Administrators are never switched off automatically. Arcvue support is alerted instead, so the hand-over happens first; switch the login off in Users when it is done.
- A login whose email someone still on payroll carries is left on, and support is alerted: a rehire, a move between payroll companies and a reissued mailbox all look alike from payroll.
- Only payroll departures count. Logins with no payroll record -- support accounts and subcontractors, for example -- are never touched.
- An unusually large batch is held. If one morning would switch off more than 10 logins, nobody is switched off that day and Arcvue support is alerted.
Seating an outside auditor
The External Auditor role is read-only across the whole grid — it can open every report on screen and can export them to PDF or Excel, and it can change nothing. A tenant administrator can seat one directly from this tab; the role is in the role list. An auditor is engaged by the company to examine the company's own books, so seating one administers a decision already taken.
The Lender seat deliberately does not work this way. A lender is a counterparty whose interests can diverge from the borrower's, and the seat exposes statements, covenants and forward cash — what a counterparty may read is a financing decision, not user administration, so it is not self-serve here.
On a new tenant the tab reads "Create the first user to get started."
Contract access — and why an empty list is not a denial
A user can be limited to specific contracts. Someone scoped to one program sees that program in the Contracts Portfolio and My Programs, and nothing else.
An empty selection means UNSCOPED, not "sees nothing". A user with no contracts selected sees everything their role allows. This is the single most misread thing on the screen, and misreading it does real harm: an administrator who takes a blank list for a denial will assign one contract to "fix" it and, in doing so, narrow somebody who had full access a moment earlier. Nothing errors, nobody is told, and the person affected simply stops seeing their own programs.
The screen states the user's current state in words above the list, and the footer says what saving an empty selection will do before you press it. Read both. If your intent is to leave someone unscoped, leave the list empty and save nothing.
Match contracts by their number, not their name. Contract names are stored as underscored slugs, so the screen renders a readable version with the real contract number beneath it. The number is the reliable identifier — the readable name is a convenience, and two programs can look alike at a glance.
Part 3 — Modules
The tab is headed Feature Modules and it is read-only: module access is set by Arcvue operations. It shows what the tenant can reach, grouped by product, and the badge on each card means something different depending on the entry's kind:
| Badge | What it means |
|---|---|
| Enabled / Disabled on a product (FP&A, Accounting, Toolsets) or a switch (a feature something gates on, such as NEO) | A real per-tenant switch. A disabled product does not degrade — its pages simply are not there. |
| Included with | The feature comes with that product and follows its state. It is not switched on its own; there is nothing to ask operations to flip for it. |
| Always on | Part of every tenant. |
So when a page a user expects is missing, check the product first: an included feature is only ever off because its product is. That is why this tab is step 1 of the troubleshooting chain rather than an afterthought.
An empty tab means module configuration will appear after tenant setup — not that the tenant has no modules.
Part 4 — Permissions (admin and CEO)
The tab is headed Permissions Matrix, and it opens on a summary rather than the full grid. Show the whole matrix is what takes you to the grid itself — worth knowing before you conclude the summary is all there is.
This is the grid of what each role can do per area. Four levels:
| Level | What it allows |
|---|---|
| No Access | The area is not available |
| Read Only | Can see, cannot change |
| Read Write | Can see and change |
| Write When Open | Can change only while the accounting period is open |
Write When Open is the one worth understanding, because it is the level
that does most of the work in an accounting tenant. It lets someone do their
job all month and stops them editing a period after it closes — without you
having to remember to demote them at close and promote them again afterwards. The
period does the gating.
So if a user reports that something they changed last week is now refused, check whether their level is Write When Open and whether the period has closed. That is the system working exactly as configured.
Reading the grid
The first column is Module / Tab — every gateable surface, one row each, with tabs nested under their module. Collapse all shuts every module at once, which is the only practical way to see the whole grid's shape before you start reading rows.
The grid is deliberately large — every role against every surface — so three things help the eye:
- The colors are ordinal, and the safe states are quiet. No Access and Read Only are most of the grid and carry the least visual weight; Read Write and Write When Open are the cells that grant change, and they are the ones that stand out. Scan for the loud cells to see where write access lives.
- Each column header says who actually holds the role — N users, N users, M disabled, M disabled, or no users. A role with no users is not a defect; it is a template for a hire that has not happened, and the header lets you skip those columns without hiding a single cell. (On a fresh tenant with no users at all the annotation does not render, because twenty-six identical no users labels would say nothing.)
- Three counts above the grid, each a lens. Write access — how many surfaces some role can change, and across how many roles (with held by nobody called out); click it to show only those surfaces. Refused — how many attempts have been refused, on how many surfaces, since observation began; click it to order the grid by where people are being refused. Not used — grants to held roles that nobody has exercised in the window; click it to show only those. A lens hides rows and says how many it is hiding; one click restores the whole grid. On a tenant where nothing has been observed yet, the usage counts read Not recorded for this tenant — which is not the same as zero, and the panel says so.
Seeding a new tenant
Backfill Defaults seeds the grid with a sensible starting set rather than making you fill every cell by hand. Do it once on a new tenant, then adjust.
Saving
Save commits your changes. The tab tells you when there is No changes to save, and warns you on the way out that changes you made may not be saved if you navigate away with edits pending — so a half-finished permission change cannot leave quietly.
Part 5 — Access Decisions — the tab that answers "why couldn't they?"
The list opens on All decisions — both grants and denials, not just the refusals — and each row carries its Timestamp (UTC). The times are UTC and labeled UTC, so a decision that looks hours away from when somebody says it happened is usually the time zone rather than the wrong row.
Every permission decision is logged here. This is the observability surface for the other three tabs, and it is the fastest route from a complaint to a cause.
| Control | Use |
|---|---|
| Filter by user | Narrow to the person who reported the problem |
| Filter by module (substring) | Narrow to the area they were in |
| Blocked only | Show just the refusals — usually the only rows you want |
| CSV export | Download the current view |
Start with Blocked only and the user's name. A refusal row tells you which module and which decision refused them, which turns "it won't let me" into a specific setting to change.
"No blocked decisions" is a good result, and distinct from "No decisions logged" — the first means nothing was refused, the second means nothing has been recorded at all, which on a live tenant is worth a second look.
Part 6 — When something looks wrong
"I'm an admin and I can't see Permissions." That is a fault, not a
restriction — the tab is open to the admin role. Check that your role really
resolves to admin (Part 2 shows the role as stored, which is not always the
label you expect), then report it.
"A user says a whole section is missing." Check Modules first. A disabled module removes the pages entirely, which reads as missing rather than forbidden.
"They could edit this last month and now can't." Look for Write When Open plus a closed period. Nothing changed about their access; the period did.
"I gave them the permission and it still refuses." Check Access Decisions with Blocked only — the refusal row names the module and the decision, which is usually a different area than the one you changed.
"Permissions is empty on a new tenant." Use Backfill Defaults to seed it, then adjust.
"Modules is empty." Module configuration appears after tenant setup.
"I reset someone's MFA and now I'm nervous." Correct instinct — that account is less protected until they re-enroll. Tell them to enroll immediately rather than at their convenience.
"Our outside auditor needs to run reports." Seat them as External Auditor from Users — read-only everywhere, with report export. Nothing to configure in Permissions.
"The Refused and Not used counts say Not recorded." Nothing has been observed on this tenant yet. That is a statement about observation, not about refusals — the Write access count still works, because it is computed from the matrix itself.
One-line summary
Access is a chain: module on → user exists → role has the permission → nothing else refuses. Users handles people and the two recovery actions (password, MFA reset). Modules decides what exists at all and is the first thing to check when a section is "missing". Permissions is open to admin and CEO and carries four levels, of which Write When Open does most of the real work by letting the accounting period do the gating. Access Decisions, filtered to Blocked only and the user, is how you turn "it won't let me" into a setting.
Related
- The settings that shape the numbers themselves → Configuration you must get right in week one
- Vendors, labor categories, holiday calendars → Accounting Settings
- Why a closed period refuses a write → Month-End Close
Part 5 — API Tokens (admin and CEO)
The tab is headed API Tokens and has two views, Tokens and Usage, switched with the API tokens view control at the top of the tab. A token lets a system outside Arcvue — a partner's application, a script, an integration — read this tenant's data through the public Arcvue API (api.arcvue.ai). Arcvue operations can issue and revoke tokens for any tenant from the Ops Console; this tab is the tenant administrator's own view of the same thing, scoped by the server to this tenant, and both write to the Audit Log.
Reading the list. Each card is one token: its label, the prefix (the only part of the token Arcvue keeps in readable form), the environment (live or test), its status, its scopes, who created it and when, when it was last used, and any rate limit or daily row quota. signing required marks a token carrying a write scope. A token issued to a portal partner names the partner; partner suspended marks one whose partner's portal access was cut off while the token itself is still live, which is why it is flagged — revoke it unless there is a reason not to. Nothing on this page can show a token again after creation — Arcvue stores only a hash.
Issuing. New token opens the form (it is unavailable while the scope list cannot be loaded, and the notice says so — a token cannot be issued without its scopes). Scopes are deny-by-default; tick what the outside system needs and nothing more. A write scope forces request signing and mints a signing secret shown once alongside the token; a PII scope cannot be issued here. Label, Environment, IP allowlist, Rate/min and Daily rows describe and bound the token. Create token issues it; Cancel closes the form.
The token is shown exactly once. Copy it — and the signing secret, if there is one — into the receiving system before pressing I have copied these — dismiss. A lost token is revoked and re-issued, never recovered.
Active, expired and revoked. The list is ordered active first, then expired, then revoked, newest first within each, and opens filtered to Active — the tokens the API accepts right now. Expired tokens passed their expiry date and are refused exactly as a revoked one is, but nobody chose that, so they are listed apart and can still be revoked to record the retirement deliberately. Revoked tokens were cut off on purpose and stay listed as the audit record. All shows every token ever issued; the count on each filter says what is there, and filtering hides nothing permanently.
Revoking. Revoke on a card opens a confirmation that names the token (label and prefix) and asks for a reason, which is recorded in the Audit Log. Revoke token confirms; Keep token backs out. Revocation is prospective: a request already in flight completes, and the next request presenting that token is refused. It cannot be undone — issue a new token instead.
Refresh re-reads the list. An empty tab means no token has been issued — nothing outside Arcvue can reach this tenant's data through the public API, which is the correct state for a tenant with no integrations.
Usage. The Usage view answers what each token actually did, read from the public API's own audit record (every request writes one row; if it cannot, the request fails, so the record cannot under-report). Pick the Usage window — 7 days, 30 days, 90 days or All time, in UTC — and optionally one Token (All tokens clears it); Errors only narrows the call history to calls the API refused or failed.
Four tiles summarize the window: Calls, Rows served, Error rate (marked whenever any call failed) and Idle tokens — active tokens with no calls in the window, each a revocation candidate. Calls per day charts the window, quiet days included; hovering a day shows its calls, rows and failures.
Selecting one token narrows Calls per day to that token alone, and its name then appears above the chart with show all tokens beside it — which clears the selection and returns the chart to every token. That control exists only while a token is selected, so it is not on screen until you have narrowed the view; if the chart looks emptier than the tiles suggest, a selection is why.
By token lists every token, busiest first, with Calls, Rows served, Errors and Last seen; an active token of your own with no calls is flagged idle (partner tokens are not — a partner looks when it has a fit, and a quiet partner is the design), and one on a suspended partner is marked partner suspended. Clicking a token's name narrows the chart, the routes and the history to it, and again clears it. Revoke on a row opens the same confirmation as the Tokens view — it names the token and records a reason — so a token the figures indict is revoked where you decided that. By route lists which parts of the API were reached, with Route, Calls and Errors.
Call history is every audited request, newest first — Time (UTC), Token, Route, Status, Rows and From, the address the call came from. The count beside the heading is the true total for the window and its filters, and Previous / Next page through it. Nothing on the view can alter or remove a usage row.