Permissions and Roles
DocumentQ ships three permission sets. Assign them in Business Central under Users → the user → Permission Sets, exactly as you would for any other extension.
| Permission set | Who it is for | What it allows |
|---|---|---|
| DocumentQ - Full (Write/Post) | AP specialists and administrators | Everything: setup, capture, resolving exceptions, registering documents, and posting. |
| DocumentQ - Triage (Read/Triage) | Reviewers who investigate exceptions but do not create ledger documents | View the queue and every decision behind it, bind vendors, authorize charge lines, override exceptions. Registering and posting are refused. |
| DocumentQ - Unlicensed (Read Only) | Anyone who only needs to look | Read the document list and card. Capture, register and post are refused. |
Choosing a seat
Full is the seat that can create and post Business Central documents. Give it to the people who own the AP ledger.
Triage is genuinely useful and often under-used. A reviewer on this seat can do all the investigative work — read the reconciliation grid, bind a vendor, authorize a charge, override an exception with a recorded reason — without ever being able to create a ledger document. If your process separates “who works the queue” from “who commits to the ledger”, this is the seat that expresses it.
Unlicensed is a genuine read-only viewer. It is what an auditor, a controller doing a spot check, or a colleague answering “did we ever receive that invoice?” should hold.
Two things worth knowing
A first-time setup needs SUPER. On a brand-new tenant nobody holds the DocumentQ seats yet. A user with SUPER can complete the whole of setup, then assign the seats afterwards.
The unattended job queue user needs the Full seat. Registering requires it even when nothing human is clicking. If the job queue entry runs as a user without it, unattended registration refuses — and the Unattended Processing page names this as the cause rather than leaving you to guess.
Permission sets and the in-product guards are two layers
DocumentQ enforces what a seat may do in two independent places: the Business Central permission set, and its own checks inside the product. Both must agree.
That is deliberate — a permission set alone would not stop a page action that a user can technically reach, and an in-product check alone would not stop direct table access. If you customise permissions, expect a user to need both the underlying grants and the matching seat.
Not yet observed. The lowest-privilege seat has not been walked through the entire product on a live tenant end to end. Everything to date has been exercised with elevated rights, which is precisely the condition under which a missing grant stays invisible. If you deploy the Triage or Unlicensed seat, it is worth a short deliberate walkthrough on a sandbox first, and worth telling us if you hit a permission error the product does not explain.