Skip to main content
Hiring someone in HR records who they are and how they’re employed. It does not, on its own, let them operate one of your business apps. App access is the bridge: it turns an employee into an operator of a product — a SACCO360 Teller, an Agri360 Farm Manager, a Law360 Associate, and so on. Access is a two-party decision. HR requests the access an employee needs; IT/Security reviews and approves it. HR never grants a product role directly, and IT owns the catalogue of what is even requestable. This keeps a clear record of who asked, who approved, and why. The flow is the same for every vertical — SACCO360, Agri360, Law360, Faith360, Health360, Retail360 and the rest all work through it.

​
The short version

  1. IT/Security publishes a catalogue of access profiles — reviewed, named roles that HR is allowed to request (a “SACCO Teller” profile, an “Agri360 Farm Manager” profile, and so on).
  2. HR requests a profile for an employee — from the employee’s profile, or while creating them. This grants nothing; it files a request.
  3. IT/Security sees the request in the Access queue and approves (or rejects) it.
  4. Once approved, the access is provisioned automatically as soon as the employee has a login. If they already have one, it’s provisioned immediately.
Why a catalogue instead of “just pick a role”? The full list of system roles is large and includes roles that should never be handed to an employee. IT curates a short, business-appropriate menu — and attaches a risk level to each — so HR requests from a reviewed list rather than the raw role catalogue.

​
For HR — requesting access

You’ll find this on any employee profile (/hr/employees/:id), in the App access panel on the Overview tab. You can also request access while creating an employee.

​
From an employee’s profile

  1. Open the employee in HR → Employees.
  2. On the Overview tab, find the App access panel. It lists any access the employee has already been granted or requested, with its status.
  3. Click Request access.
  4. Pick an access profile from the list — e.g. SACCO Teller, Loan Officer, Farm Manager. Only profiles for apps this business runs appear.
  5. Click Request access to submit.
The request is filed and shows as Waiting for IT approval. Nothing has been granted yet.
📷 Screenshot: The App access panel on the employee Overview tab, with the Request access dialog open and a profile selected — to be added.

​
While creating an employee

The Add Employee form has an Access requested card. Tick “This employee needs to log in and use an app,” pick a profile, and finish creating the employee — the request is filed automatically after the employment record is created. The card states plainly that access is not granted on save; IT/Security reviews it first.
The request is only filed once the employment record saves. Access is an attribute of employment, so an employee with no contract in this business can’t be requested for access — if the employment step fails, you’ll see “Employment must be completed before access can be requested.”

​
What the statuses mean

The panel shows one of these, and only these: HR can request and see status. HR cannot approve, reject or revoke — those are IT/Security decisions and the controls don’t appear on the HR side at all.

​
For IT / Security — approving and managing access

Everything IT does lives under Settings → User Management → Access. It has two views: Requests (the queue) and Profiles (the catalogue).

​
The Requests queue

  • Pending shows requests Waiting for IT approval. History shows everything decided — approved, provisioned, rejected, revoked, failed, cancelled.
  • For each pending request you can:
    • Approve — snapshots the role and provisions it (immediately if the employee has a login; otherwise it waits for one).
    • Reject — a reason is required; it’s shown back to HR.
  • For access already granted, from History you can:
    • Revoke — removes the access. The employee’s login is not deleted, and access to other products is untouched.
    • Retry / Cancel — a request that Failed can be retried, or cancelled to free the slot.
An employee holds one active access request per business at a time. Approve or resolve the current one before a new one can be filed for that business.
📷 Screenshot: The Access → Requests queue with a pending request and the Approve / Reject actions — to be added.

​
The Profiles catalogue

A profile is one entry HR can request: a name, the app and role it maps to, and a risk level. The catalogue starts empty — nothing is requestable until you add profiles.
  • Create a profile: give it a name, pick the app and the role, set the risk level. (The catalogue is honest about being empty until you populate it — that’s expected on a new tenant.)
  • Edit: you can always change a profile’s name, description and whether it’s active. Once a profile has been used by a request, its app, role and risk level lock — history renders what was actually granted, so a profile’s identity must not drift underneath it. Deactivate it and create a new one instead.
📷 Screenshot: The Access → Profiles catalogue with the New profile form — to be added.

​
Break-glass — granting directly

For an emergency where the normal request-then-approve path is too slow, an administrator can grant access directly from an employee profile’s App access button in the header. It still selects a profile (never a raw role) and requires a written justification. The grant is applied immediately and recorded in the Access History as a break-glass grant, with your name and the reason — it is never hidden.

​
Does it behave the same for every vertical?

Yes — the request-and-approve flow is identical whatever the product. There’s one difference under the hood, invisible to you:
  • SACCO360 is a separate application, so a provisioned grant also sets the person up on the SACCO side automatically. A fresh SACCO operator starts with no home branch assigned — they can work right away, and a SACCO administrator can set the branch later.
  • The in-platform verticals (Agri360, Law360, Faith360, Health360, Retail360, …) are complete the instant the request is provisioned.

​
Who can do what

The HR App access panel and its Request access action appear for HR users who can manage employees. The Access tab, the approval controls and the break-glass button are administrator-only.

​
What happens when someone leaves

When an employee’s contract in a business ends, their access for that business is revoked automatically — pending requests are cancelled and provisioned access is removed. Access they hold in other businesses (for someone who works across more than one) is left untouched.