User management
Who can send, approve, generate, configure. The model fits in one sentence: one role, plus options.
The model
The 4 roles — one per person
| Role | Permission set | Purpose |
|---|---|---|
| Administrator | TES_Admin | Configures the org: connections, jobs, buttons, migration, users |
| Sender | TES_User | Sends for signature and tracks their requests |
| Approver | TES_Approver | Approves or rejects — does not send |
| Viewer | TES_ReadOnly | Read-only access |
The 4 options — zero or more, on top of the role
| Option | Permission set | Unlocks |
|---|---|---|
| Bulk send | TES_BulkSendUser | The Bulk send tab |
| Document generation | TES_GenUser | TrueSign Gen |
| Template management | TES_TemplateManager | The template editor |
| Approval delegate | TES_ApprovalDelegate | Deciding on behalf of an absent approver |
The matrix
What each combination actually allows — measured at runtime, not inferred from configuration:
| Configuration | Send | Bulk send | Generate | Manage templates | Configure the org |
|---|---|---|---|---|---|
| (no permission set) | — | — | — | — | — |
| Administrator | ✅ | ✅ | ✅ | ✅ | ✅ |
| Sender | ✅ | — | — | — | — |
| Approver | — | — | — | — | — |
| Viewer | — | — | — | — | — |
| Sender + Generation | ✅ | — | ✅ | — | — |
| Sender + Bulk send | ✅ | ✅ | — | — | — |
| Sender + Templates | ✅ | — | — | ✅ | — |
| Sender + all 4 options | ✅ | ✅ | ✅ | ✅ | — |
| Approver + Generation + Templates | — | — | ✅ | ✅ | — |
Three readings that matter
The administrator needs no options. TES_Admin on its own carries sending, generation, bulk send and templates. An administrator locked out of their own configuration would be an incident, not a security measure.
An approver cannot send, even with all four options. This is separation of duties: approving and issuing are two distinct acts, and combining them would empty the approval workflow of its meaning.
Sender + all 4 options ≠ Administrator. That is precisely what justifies the administrator role: do everything, except configure the org.
The rules the server enforces
They are not merely displayed in the screen: they are verified server-side, including when someone bypasses the interface.
| Rule | Behaviour |
|---|---|
| One role only | Assigning a second role is refused |
| An option requires a role | Assigning an option to someone with no role is refused |
| No orphan option | Removing the last role is refused while options remain |
| Atomic role change | The change happens in a single operation and keeps the options |
| Full removal | Clearing the role removes the options along with it |
Changing a role in several steps (remove, then assign) leaves a window where a mid-way failure strands the user with no access at all, and nothing signals it. The operation is therefore indivisible.
Where this is set
TrueSign Setup → Administration → User Management: role and options per user, with search, and usage tracking (number of sends, last send).
Who can do what, screen by screen
| Screen or action | Requires |
|---|---|
| Send a request (form, Quick Send, auto-send after generation) | Sender role or Administrator |
| Bulk send tab | Bulk send option + sending rights |
| Setup → Document Generation | Generation option |
| Signature template editor | Template management option |
| TrueSign Setup (configuration) | Administrator |
| Setup → User Management | Administrator |
"Can a user without sending rights still issue an envelope?" — No, on none of the three paths: not the form, not Quick Send, not the auto-send triggered after a generation. That last one runs in the background, and it is verified that no request is created, not merely that an error is raised.
Special case: the Site guest user
TES_Guest is not a user role. It is assigned to your public Site's guest user so that external signers can reach the signing pages — never to a person in your org. See Installation.