Skip to content
Operations guide / proposed design

The same platform.
A path that fits every organisation.

A practical view of roles, steps, and controls from procurement to HR. Each path shows what is confirmed in the product description, then proposes an operating cycle to match against the system before adoption.

How do we build customisation?

We start with a process template, then the organisation configures roles, fields, conditions, and approvals. Policies are reviewed by office, grant, donor, and amount — instead of building a separate system for each organisation.

Steps and roles

Who requests? Who reviews? Who approves? Who executes? Prefer assignment to a functional role with a delegated alternate and a clear duration.

Conditions and exceptions

Amount, currency, office, grant, and request type determine the path, with a clear rule order when they conflict.

Statuses and history

Draft, under review, returned for correction, approved, in progress, completed, or cancelled; status names and details are part of the design.

Currently confirmed: RBAC roles, configurable approvals, and security controls. A visual path editor, advanced rules, policy versions, timers, and escalation are proposed items that need verification or development; this page does not change ERP settings.

Supplier registration and qualificationProcurement: from request to paymentGrants, budgets, and amendmentsProgrammes, MEAL, and reportingPartners and sub-grantsInventory and warehousesFinance, spend, and reconciliationsHiring and ATSEmployee lifecycle: onboarding, changes, and offboardingLeave, attendance, and timePayroll setup and approvalTravel and related advancesOffices and visitorsRoles, security, and exportBulk import and search
Interactive example / procurement

Change the rule, and watch the path.

This is an educational simulation with a default policy — not a recommended finance policy or a setup applied to your organisation.

Proposed approval path

    In live use, currency, mandatory documents, and segregation of duties are defined, and the policy version is locked to the request when it is submitted.

    Procurement and specialist reviewer

    Supplier registration and qualification

    Confirmed in the product: A portal for vendor registration and public quotes; detailed qualification is a proposed model.

    Suggested operating cycle

    1. Vendor: submit registration details and required documents
    2. Procurement: review completeness and duplicates
    3. Specialist reviewer: assess qualification requirements and conflicts of interest per policy
    4. Authoriser: approve the vendor or request completion
    5. Procurement: enable participation in bids within the approved scope
    6. Team: review vendor data changes and how often the profile is updated

    What does the organisation configure?

    • Document checklist by vendor category
    • Vendor approval authority and payment-detail changes
    • Qualification validity period and re-evaluation process
    Control or exception

    Registration is not qualification. Changing payment details requires independent verification and a review path before use.

    Procurement, finance, and budget holder

    Procurement: from request to payment

    Confirmed in the product: Purchase requests, configurable approvals, RFQ, purchase orders, and linking the purchase–approval–payment chain with an audit trail.

    Suggested operating cycle

    1. Requester: define need, quantity, grant, and budget line
    2. Budget holder: review need and funding availability
    3. Procurement: select the purchase path and collect quotes
    4. Evaluation committee: technical and financial comparison and documented selection
    5. Authoriser: approve the award and issue the purchase order
    6. Receiver: document receipt and acceptance or shortfall
    7. Finance: match purchase order, receipt, and invoice
    8. Payment authoriser: approve payment, then document it and close the request

    What does the organisation configure?

    • Amount thresholds, currency, and conversion method
    • Number of quotes and allowed exceptions
    • Approvers by office, grant, donor, and purchase type
    • Segregate requester, evaluator, receiver, and payment approver
    Control or exception

    A budget shortfall stops commitment. Invoice or receipt variance returns the request for review. Emergency purchase needs a reason and a documented exceptional approval path.

    Grants officer, programmes, and finance

    Grants, budgets, and amendments

    Confirmed in the product: Budgets, amendments, spend, and donor reports within the grants hub.

    Suggested operating cycle

    1. Grants officer: create the grant record, donor, period, and currency
    2. Programmes and finance: set up activities and budget lines
    3. Review: audit donor conditions and spending limits
    4. Authorised officer: approve the budget and activate the delivery scope
    5. Departments: deliver activities, procure, and spend against the grant
    6. Grants officer: review BvA and submit periodic reports
    7. On amendment: document the request and reason, then issue an approved version
    8. On close-out: settle commitments, review the report, and archive

    What does the organisation configure?

    • Line structure, cost centres, and donor templates
    • Amendment approval authority and reallocation limits
    • Alert before grant end and report deadlines
    Control or exception

    An approved budget history is not silently replaced. Amendments after commitment or spend need an audit trail showing version, reason, and approval.

    Programme manager, MEAL team, and field collection

    Programmes, MEAL, and reporting

    Confirmed in the product: Activities and indicators on the grant, field collection, QA, and export to the donor.

    Suggested operating cycle

    1. Programmes: define activities, outputs, and measurement indicators
    2. MEAL: define data sources, frequency, and verification method
    3. Manager: approve the plan and access roles
    4. Field team: collect data within scope
    5. Quality reviewer: check completeness, duplicates, and consistency
    6. Programmes and MEAL: analyse progress and document corrective action
    7. Report owner: approve outputs and export for the donor
    8. Team: capture lessons and improve the next plan

    What does the organisation configure?

    • Collection forms, indicators, baseline, and targets
    • Review on a sample or the full dataset
    • Sensitive-data privileges and the complaints path when implemented
    Control or exception

    Unacceptable data returns for correction and is not automatically included in an approved report. A beneficiary complaints path needs a dedicated privilege separation if it is in scope.

    Partnerships, grants, and finance

    Partners and sub-grants

    Confirmed in the product: Partners, invitations, sub-grants, and a partner portal.

    Suggested operating cycle

    1. Partnerships: register the partner and invitation
    2. Reviewer: check documents and qualification requirements
    3. Grants and finance: set up the sub-grant scope and budget
    4. Authoriser: approve the agreement and the partner’s access scope
    5. Partner: submit delivery information and required reports
    6. Programmes and finance: review performance, spend, and findings
    7. Authoriser: approve disbursements per agreed conditions
    8. Close-out: complete reports and reconciliations, and revoke access when needed

    What does the organisation configure?

    • Partner checklist
    • Disbursement conditions and reporting frequency
    • Fields and grants each implementing partner can see
    Control or exception

    A late report or missing document stops the relevant step per policy, with the reason and follow-up owner documented.

    Warehouses and logistics

    Inventory and warehouses

    Confirmed in the product: Warehouses and inventory linked to procurement and grants.

    Suggested operating cycle

    1. Warehouse: receive against the purchase-order reference
    2. Receiver: check quantity and condition and document acceptance
    3. Storekeeper: enter materials and location and link them to the grant
    4. Requester: request issue or transfer of materials
    5. Authoriser: approve the issue or transfer
    6. Final receiver: confirm delivery and update the balance
    7. Stocktake team: compare physical balance to the record
    8. Manager: approve stocktake variances or adjustments

    What does the organisation configure?

    • Warehouses and storage locations
    • Approval levels for issue, transfer, and adjustment
    • Extra tracking requirements such as batches after availability is confirmed
    Control or exception

    Short or rejected materials are recorded separately. Direct balance edits without reason and approval are not the normal path.

    Accountant, finance manager, and payment authoriser

    Finance, spend, and reconciliations

    Confirmed in the product: Spend is linked to grant lines with approvals and the operational trail.

    Suggested operating cycle

    1. Requester: submit a claim or commitment with supporting documents
    2. Accountant: review the line, grant, currency, and payee
    3. Reviewer: check budget, documents, and required matching
    4. Authorised officer: approve the finance request
    5. Payment authoriser: execute payment via the approved channel
    6. Accountant: record the payment reference and update spend
    7. Reviewer: reconcile advances and transactions and match records
    8. Finance manager: review BvA and close the period per procedures

    What does the organisation configure?

    • Approval limits by amount and grant
    • Paths for advances, reimbursements, and vendor invoices
    • Required documents and segregation rules between preparation and payment
    Control or exception

    The same payment is not re-run on retry. Correction after finance approval uses a documented adjustment; journals, period close, and bank integration are reviewed technically before adoption.

    Department manager, HR, and hiring committee

    Hiring and ATS

    Confirmed in the product: Hiring, job requests, and ATS applicant tracking.

    Suggested operating cycle

    1. Department manager: submit hiring need and funding
    2. Finance and management: approve the vacancy and scope
    3. HR: prepare the job description and open applications
    4. HR: screen applications against criteria shared with the team
    5. Committee: interviews, assessments, and documented decision
    6. Authorised officer: approve the candidate and offer
    7. HR: complete documents and offer acceptance
    8. HR: hand employee data to the onboarding path

    What does the organisation configure?

    • Number of interviews and committee members
    • Assessment criteria and who can see candidate data
    • Approval stages, exceptions, and retention period
    Control or exception

    A candidate is not converted to an active employee before the hiring decision is complete. Any committee conflict of interest needs handling per organisation policy.

    HR, line manager, and IT

    Employee lifecycle: onboarding, changes, and offboarding

    Confirmed in the product: Employees, organisational structure, leave, time, and payroll.

    Suggested operating cycle

    1. HR: prepare the employee file and place in the org structure
    2. Authorised officer: approve the appointment and core data
    3. HR and IT: prepare onboarding requirements and the work account
    4. Manager: follow tasks and probation per policy
    5. On change: request a transfer or data edit, then review and approve it
    6. On departure: confirm last day and handover requirements
    7. HR and finance: review entitlements and accountabilities by scope
    8. IT: revoke access and archive the file per retention policy

    What does the organisation configure?

    • Contract types, offices, and managers
    • Onboarding and offboarding checklists and change review
    • Payroll and personal-document privileges
    Control or exception

    Payroll and identity data are not automatically available to all managers. Changes with financial impact return to finance review before they take effect.

    Employee, manager, and HR

    Leave, attendance, and time

    Confirmed in the product: Leave, time, and attendance — basic, face, QR, or IP — plus an employee portal.

    Suggested operating cycle

    1. Employee: submit leave or record time and attendance
    2. Policy: validate dates and required information
    3. Manager: review operational cover and approve or return the request
    4. HR: review exceptions and balances when they apply
    5. Employee: request a justified correction for any incorrect record
    6. Reviewer: approve the correction while retaining history
    7. HR: approve the period summary before payroll calculation

    What does the organisation configure?

    • Leave types, calendar, and working days
    • Allowed attendance method per office
    • Overtime rules, corrections, and submission windows
    Control or exception

    An approved record is not edited without a clear audit trail. Payroll impact needs agreed rules and local policy review.

    HR, finance, and payment authoriser

    Payroll setup and approval

    Confirmed in the product: Payroll, time, and leave functions within HR; calculation details are set during implementation.

    Suggested operating cycle

    1. HR: lock employee data and approved inputs for the period
    2. Payroll officer: prepare the draft per defined rules
    3. HR: review changes, leave, and time
    4. Finance: review figures, funding, and allocation if in scope
    5. Authoriser: approve the final payroll version
    6. Payment officer: execute disbursement and document the reference
    7. Review: resolve variances and close the cycle

    What does the organisation configure?

    • Payroll frequency, currency, and earning and deduction elements
    • Country rules and reporting requirements after review
    • Approval levels and time or cost allocation to grants
    Control or exception

    A payroll version is not silently edited after payment. Variances are handled with a clear adjustment. Payroll compliance for every country is not assumed without verification.

    Employee, manager, operations, and finance

    Travel and related advances

    Confirmed in the product: Travel clearances from the employee portal; advances and settlement here are a proposed extension that needs matching to the system.

    Suggested operating cycle

    1. Employee: request travel clearance, purpose, and dates
    2. Manager: confirm travel necessity and cover
    3. Operations: review destination requirements and arrangements
    4. Finance: review the estimate and funding line if required
    5. Authoriser: approve the clearance and any advance within scope
    6. Employee: complete travel and prepare documents
    7. Finance: settle expenses and advance and close the file

    What does the organisation configure?

    • Domestic or international travel
    • Destination approvals and safety requirements
    • Expense and advance limits and settlement deadline
    Control or exception

    Cancelled travel needs a clear close-out and settlement of any amounts. Direct flight and hotel booking is unconfirmed within product capabilities.

    Reception, host, and operations

    Offices and visitors

    Confirmed in the product: Offices, visitors, and workplace forms.

    Suggested operating cycle

    1. Host: create a visit request or workplace form
    2. Operations: review office, timing, and information
    3. Authorised officer: approve the request when required
    4. Reception: verify the visit on arrival
    5. Host: follow up the visit or request
    6. Reception: record departure or close the request

    What does the organisation configure?

    • Offices and access zones
    • When a visit needs approval
    • Required fields and visitor-data retention period
    Control or exception

    Connection to access-control devices is not assumed. Handling unscheduled visits needs a path defined by the office lead.

    Process owner, IT, and specialist reviewer

    Roles, security, and export

    Confirmed in the product: RBAC, MFA, step-up, sessions, IP, segregation of duties, and export audit.

    Suggested operating cycle

    1. Manager: request access that defines role, reason, and duration
    2. Data owner: review need and privileges
    3. Security officer: review role conflicts and controls
    4. Authoriser: approve the change then apply it
    5. User: perform the action with extra verification (e.g. MFA) when policy applies
    6. Reviewer: review exports, sessions, and changes
    7. IT: revoke access when need ends or on departure

    What does the organisation configure?

    • Roles per office and grant
    • Actions that need extra verification
    • Temporary delegation and periodic access review
    Control or exception

    Conflicting role combinations are rejected per policy. Urgency does not waive the audit trail or grant permanent open-ended access.

    Data steward, department owner, and IT

    Bulk import and search

    Confirmed in the product: Bulk import and comprehensive search; batch-log and rollback elements are proposed for implementation.

    Suggested operating cycle

    1. Data owner: define source, scope, and fields
    2. Data steward: clean duplicates and references
    3. Team: map fields and trial a sample in a sandbox
    4. Department owner: review counts, balances, and relationships
    5. Authoriser: approve the migration batch and cut-over date
    6. Team: run the import and review errors
    7. Department owner: accept results and enable search by privilege

    What does the organisation configure?

    • Import templates and mandatory fields
    • External keys and preventing re-entry of the same record
    • Data sequence and acceptance owner for each set
    Control or exception

    Failure does not mean blindly re-running a full batch. Accepted and rejected records and a rollback plan are defined before migration.

    Shared rules for every process

    • Rejection needs a reason, and return for correction states what is required; a notification is not an approval.
    • Any material change after approval — such as amount, grant, or payee — reopens review per policy.
    • Escalation after delay goes to a defined role and does not auto-approve the request.
    • Cancellation after a finance or inventory action is handled with an approved adjustment, not by deleting the trail.
    • Conflict cases, missing reviewer, duplicate request, and notification failure are tested alongside the happy path.
    • The audit log records who acted, when, what changed, the reason, attachments, and the rule version when available.
    • Parallel approvals are proposed only when one review does not depend on another’s outcome, with a clear completion rule.

    How do we adopt the path for your organisation?

    For each process: define its owner, inputs, outputs, and privilege matrix, then test a normal case, exception, rejection, return, and cancellation. The team records gaps between the proposed model and current capabilities before agreeing customisation.

    Discuss your organisation’s paths ↗