Roles, permissions & approvals

Permissions & roles

A permission is a single capability — "can manage leave", "can approve exits", "can view budgets". You give each person a set of permissions, and Hubtoll checks them on every action. A role is just a saved bundle of permissions you can reuse, so you don't hand-pick them one by one for every new hire.

The person who creates your company starts with full access. From there, you decide exactly how much each colleague can see and do.

Kinds of permission

Most modules offer the same consistent family of permissions, so once you recognise the pattern you can read any of them at a glance:

Some modules split further by area — for example, Employee records has separate permissions for staff records, office locations and departments.

Company-wide roles

A few broad grants save you from assigning module permissions one at a time:

Configuring a module's approval workflow is granted per module — by that module's own Workflow editor permission (for example, the leave workflow editor configures leave approvals, the budget workflow editor configures budget approvals). A SUPER_ADMIN can configure any module's workflow.

Granting access

To manage who can do what:

• Open your list of corporate users (the all-users admin screen).
• Choose a person and open their permissions.
• Permissions are grouped for you — Top-level, Corporate management, Human resources (employee, leave, budget, exit, assets, recruitment, timesheet, learning, appraisal, forms, subscription) and Document management — so you can find what you need quickly.
• Tick the capabilities they should have and save.

To reuse a common set — say "Department manager" or "HR officer" — save it as a named role and apply it to future people in one click.

Approval workflows

An approval workflow is an ordered chain of steps that a request travels through before it's finalised. You build one per module (leave, budgets, exits, appraisals, asset assignments, recruitment, timesheets, employee records and more), and each step names who must approve.

Workflows are how Hubtoll matches your real chain of command — whether that's a single manager sign-off or a multi-level review. A workflow can also be set to no approval required, in which case requests are accepted automatically.

Choosing approvers for a step

Each step in a workflow points at an approver by category, so the right person is found automatically for every request — no need to hard-wire specific names everywhere:

The department options come in two flavours: a department you fix when you design the workflow, or the department the submitter names on the form. Finance, project and standalone Forge workflows offer the people-and-role options only — they can run without any employee records.

Building a workflow

Every module has a Business process management (BPM) screen in its settings. There you:

• Choose the workflow type — for new requests (Create) or for edits to already-approved records (Update).
• Choose whether approval is required. If not, requests are auto-approved and no steps are needed.
• Decide whether the submitter can edit the record before approval starts.
• Add your steps in order. The first step is the initiator (raising the request completes it), so your real approvers begin at step two.
• Pick the send-back behaviour (below), then switch the workflow active.

Configuring workflows requires the workflow-editor permission (or a company-wide admin role).

Approve, reject, redirect

When a request reaches an approver, they have three choices:

• Approve — the request moves to the next step. When the final step approves, the request is fully approved.
• Reject — the request is declined and stops there.
• Redirect — send the request back to an earlier step. Choosing "request changes from the initiator" sends it back to the submitter to edit and resubmit; choosing another step sends it to that approver.

Approving a middle step doesn't finalise anything — the request simply advances. It's only complete when the last step signs off.

Send-back behaviour

When a redirected request is approved again, where does it go next? That's the redirect-back-to-sender setting on the workflow:

• On — after the fix is approved, it goes straight back to the person who asked for the change.
• Off — normal forward flow resumes from the next step in sequence.

This lets you choose between "come back to me once you've fixed it" and "carry on down the chain".

Approving edits after the fact

Sometimes a record needs to change after it's already been approved. Configure a second workflow for that module on the designer's Change requests tab, and editing an approved record then raises a change request instead of rewriting it: a separate request carrying your change, routed for approval on its own. The approved record stays in force the whole time, and only when the change request is approved does it replace the original — the original is then marked cancelled, so lists and totals never count both. A rejected change request leaves the original exactly as it was. Only one change request can be open on a record at a time, and only the person who raised the record can start one. If you don't set up a Change requests workflow, approved records simply stay locked.

Where approvals appear

When a request needs someone's attention, Hubtoll notifies the right approver in-app and by email, with a link straight to the approval screen. Each module has its own approval view where approvers act and can see the full decision history — who approved, who sent it back, and when.

When a step can't run

Sometimes a step in a workflow can't do its job: an email step whose To line comes up empty (a line manager's address for someone who has no line manager), an email template that was switched off or deleted, or an approval step that resolves to nobody (a role with no members, or a "person picked on the form" that was never filled in). Hubtoll doesn't guess in those cases — it doesn't skip the step, and it doesn't send the email to the person who raised the record instead. The record is held at that step with a Workflow Error that says what stopped it and what to fix, and nothing after that step happens: a finance document doesn't post, a leave request isn't approved.

• The error shows on the record itself, to the people who administer that module — company admins, the module's workflow editors and its record editors. Everyone else sees the record as pending, exactly as before.
• The dashboard tells those administrators how many records are being held, with a Review list to work through.
• Fix the cause — add another address to the template's To line, set the line manager, add someone to the role, switch the template back on — then choose Retry Step. The record carries on from that step, and the trail shows who re-ran it.
• Administrators can also choose Re-Run Current Step on any record that is still in progress, even one that isn't held.

Good to know

• One active workflow per type, per module. Turning a new one on automatically turns off the previous active one of the same type — so there's never any ambiguity about which chain is in force.
• A workflow that requires approval must have at least one step.
• Some modules add their own time limits on top (like a deadline window) — those are enforced in addition to the approval chain.
• Workflow setup is scoped: an appraisal administrator, for example, configures appraisal workflows only.