Roles are assigned by your Administrator or your HR team. If you need access to a feature that is not available to you, contact them to discuss a role change.
Built-in roles
Credit Officer
Captures new loan applications and manages the member relationship at intake. Can search, create, and edit member records, submit KYC information, add or remove guarantors and their supporting documents, and submit completed applications for adjudication. Sees only their own loans.
Adjudicator
Reviews submitted loan applications and makes credit decisions. Can approve, decline, or request additional information. Has read access to all loans across all branches, can claim unassigned loans from the team queue, and can transition loans through workflow stages.
Securities
Reviews and resolves collateral documentation attached to a loan. Can raise security requests and review and fulfil them, ensuring all pledged assets are properly documented before disbursement proceeds. Can claim unassigned securities work from the team queue.
Disbursement
Executes approved loans by scheduling and releasing funds. Manages the payee directory used to route payments. Can claim unassigned disbursement work from the team queue, and is responsible for confirming that disbursement instructions are complete and accurate before funds leave the credit union.
Credit Manager
Oversees lending operations across all branches. Can view all loans regardless of branch, assign or reassign loans to officers, manage the loan product catalogue, publish updated rate tables, edit the standing fee schedule, apply manual rate overrides on individual loans, and access analytics and reports. The manual rate override (
loans.override) is a Credit Manager lever that Adjudicators deliberately do not hold, keeping pricing separate from the approve or decline decision.Branch Manager
Manages lending activity within their branch. Can view all loans in their branch, assign loans to officers within that branch, and view branch-level reports.
Administrator
Administers the workspace. Manages users, invitations, roles, branding, loan products, rate tables, the fee schedule, and all workspace configuration, and can run the full loan capture flow. Alongside the HR role, it invites new staff and changes role assignments; unlike HR, it also suspends members, manages lending configuration, and runs the loan capture flow. It does not adjudicate loans, review securities, or disburse funds. Those stages belong to the Adjudicator, Securities, and Disbursement roles.
HR
Handles workspace staff administration. Invites new team members, assigns and changes their roles, and deactivates departing accounts, the same user management an Administrator does. HR is deliberately walled off from lending: it cannot open member records, view or decide loans, or move funds. Keeping the person who provisions accounts away from money and member data is a segregation-of-duties safeguard your regulator expects.
Staff
A front-desk lookup role with the lightest footprint. Staff can search the member directory to confirm a member’s branch and status, and nothing more. They never see contact or demographic details, never see the sensitive identifiers such as TRN, licence, or bank account, and hold no loan, disbursement, or administration access.
Role capabilities at a glance
The table below summarises what each role is permitted to do.The Administrator runs the loan capture flow and sees every loan through its all-loans read, but it holds none of the adjudication (
loans.adjudicate), securities (securities.review), disbursement (loans.disburse), or payee-directory (disbursements.payees.manage) capabilities. Five roles see loans across all branches through loans.read.all: the Adjudicator, Securities, Disbursement, Credit Manager, and Administrator. That all-branches read is a superset of the branch-scoped view. Only the Branch Manager holds the branch-scoped loans.read.branch.Disbursement controls split the work across two roles on purpose. The Disbursement officer is the maker: they screen payees for AML and sanctions (
disbursements.screen), advance the settlement status (disbursements.settlement.update), and reverse a released disbursement (disbursements.reverse). The Credit Manager is the checker: they approve a held disbursement (disbursements.approve) and configure the control thresholds (admin.disbursement.config). Keeping approval out of the Disbursement officer’s hands means the person who releases funds is never the only person who signs off, so maker is never checker. See Disbursement controls and Settlement.Recording collateral and holding a member’s own funds sit with the securing and disbursing roles. Recording or adjusting the collateral on a loan, and placing or releasing a security hold (a lien) on a member’s shares or savings, are held by the Securities officer, the Disbursement officer, the Credit Manager, and the Administrator. A hold ring-fences the member’s pledged funds so they cannot be withdrawn while the loan is outstanding, and it is released when the loan settles. The Credit Officer, the Adjudicator, and the Branch Manager can view a loan’s holds but cannot place or release one, and the HR and Staff roles hold none of this. A hold stays visible on the member’s own profile for as long as it is in force.
Guarantor documents follow the same access as member documents. The three guarantor-document capabilities,
loans.guarantors.documents.view, loans.guarantors.documents.upload, and loans.guarantors.documents.delete, are granted to exactly the same roles that hold the matching members.documents.* capability. So the Credit Officer, Adjudicator, Securities, Disbursement, and Administrator can view a guarantor’s ID, income, and employment files; the Credit Officer, Securities, and Administrator can upload them; and the Credit Officer and Administrator can remove them. A reviewer who can open a member’s file can open the guarantor’s file on the same loan, and no wider.Editing the fee schedule is held by the Credit Manager and the Administrator through the
fees.manage capability. A Branch Manager does not hold it. This is the standing fee catalogue, the processing fee, legal, valuation, stamp duty, and the rest, that pre-fills every disbursement. A Disbursement officer still waives or adjusts a single loan’s fees at funding, but the catalogue itself is a manager-level setting. The same two roles also set the General Ledger account each fee posts to on the disbursement sheet, so a fee books to the right account and the double entry stays balanced. See Edit the fee schedule.Changing the Mandatory Shares policy is reserved for the Systems Administrator. The Mandatory Shares figure is the flat share amount a member must hold, set once for the whole workspace. Only the Administrator, your Systems Administrator, can change it. It is deliberately not delegated to the Credit Manager the way the fee schedule is. The separate Minimum Shares percentage, which can differ by loan product, is a per-product lending setting changed with the rest of your loan configuration.
Legal documents split preparing from reversing. The stage operators prepare and file the documents for their own stage: a Credit Officer handles the draft-stage consent and declaration, Securities handles the guarantee and the security agreement, and Disbursement handles the disbursement sheet, all through
loans.legal_documents.prepare and loans.legal_documents.execute. Voiding a prepared or executed document is a supervisory control (loans.legal_documents.void) held by the Adjudicator, the Credit Manager, and the Administrator, so the person who prepares a document is never the one who reverses it. Everyone in the loan’s pipeline can view legal documents (loans.legal_documents.view). The template catalogue itself (documents.templates.manage) is a Credit Manager and Administrator setting, alongside products, rates, and fees. See Legal documents and Document templates.Loan migration is open to four roles, and sign-off is optional. Bringing your existing loan book onto the platform uses three capabilities:
loans.import.upload to upload and stage a workbook, loans.import.review to review, attribute, and reconcile the staged loans, and loans.import.signoff to record the sign-off, commit a batch, and void one. All three are held by the Credit Officer, the Credit Manager, the Branch Manager, and the Administrator, and no other role holds any of them. There is no maker-checker on import: anyone with migration access can commit the ready loans, with or without a recorded sign-off first. That dual-control separation exists only on the live disbursement path, where money actually moves, not on migration. A former officer who is no longer on staff is recorded as a historical actor: they appear in the attribution picker so migrated work is credited to them, but never in the assignment picker, and they cannot sign in. See Loan migration.HR and Staff
The lending roles above all work loans and member records. Two more roles sit outside that flow: one runs staff administration, the other is a light front-desk lookup. Both are walled off from lending and member data by design. The HR role does the same user administration an Administrator does, and nothing else. HR invites and manages staff accounts and assigns their roles, so a credit union can hand employee onboarding and offboarding to its people team without also handing over member records or the ability to move money. This separation is deliberate. Because HR grants roles, letting HR also approve disbursements or read member files would give one person both sides of a sensitive action, so those capabilities are kept out of HR entirely. The Staff role is the least-privilege front-desk lookup. Its only access is a masked member directory: search for a member and see their name, member number, branch, and active or suspended status. That is enough to confirm you are talking to the right member and route them to the right person. It never reveals contact details, dates of birth, employment, next of kin, or the encrypted identifiers, and it holds no create, edit, loan, disbursement, or administration power.HR provisions accounts but never touches money or member data. This is segregation of duties. The role that can assign other people’s roles is deliberately blocked from disbursement approval and from reading member records, so no single person can both grant themselves a path and use it. The Administrator remains the all-in-one workspace owner; HR is the narrower, staff-only administrator.
How roles are assigned
Roles are chosen at the point of invitation. When an Administrator or an HR user sends an invitation, they select the appropriate role before the email is sent. The new team member joins with that role active from their very first sign-in. Each user holds exactly one role per workspace. If someone’s responsibilities change, an Administrator or HR updates the role at any time from Administration → Team & roles. A Credit Officer promoted to Credit Manager is one example. Changing the role replaces the previous one rather than adding a second, and the new role takes effect on the user’s next page load. The Administration → Team & roles page also shows a per-role permissions panel, so an administrator can see exactly which capabilities each role in the workspace holds, including the HR and Staff roles.Capability stacking
Some actions require more than one capability to line up before they succeed. Capability stacking enforces separation of duties: gaining one capability is never enough on its own to perform a sensitive action, which keeps a single role misconfiguration from opening up sensitive actions unexpectedly.Example: submitting a loan application
Example: submitting a loan application
Submitting a loan for adjudication moves it from DRAFT to SUBMITTED, and that transition stacks three capabilities plus a data check:
workflows.transition, the global workflow engine gate.loans.transition, the loan-domain gate.loans.submit, the per-transition capability, granted to Credit Officers and Administrators.- The member’s KYC is Verified. The member’s
kycStatusmust equalVERIFIEDbefore submission is allowed.
Example: transitioning a loan through a workflow stage
Example: transitioning a loan through a workflow stage
Moving a loan from one stage to the next, for example from Approved to Securities, requires three layers:
workflows.transition, the global workflow engine gate.loans.transition, the loan-domain gate, which ensures the transition request is for a loan workflow and not another workflow type.- The per-transition capability for that specific move. The adjudication moves and the moves into and through the securities stage (including Approved to Securities) require
loans.adjudicate. The moves that return a loan from Securities back to Draft or Adjudication requiresecurities.review, and the disbursement moves requireloans.disburse.