Workflows

From an employee’s request to a decision, with the balance moving at each step. Who takes part: Employee, Manager, HR Admin

flowchart TD
  A[Employee: Request leave · preview shows the day count] --> B{Valid?}
  B -- "terminated / no working day / overlap / no balance / document missing / too far back" --> X[Refused with a reason]
  B -- yes --> K{Approval needed?}
  K -- no, type auto-approves --> G
  K -- yes --> C[Pending · days added to pending]
  C --> D{Approval workflow active?}
  D -- yes --> E[Workflow steps · SLA · escalation]
  D -- no --> F[Approver decides]
  E --> F
  F -- Approve --> G[Approved · pending → used]
  F -- Reject + reason --> H[Rejected · pending released · reason shown]
  C -- Employee cancels --> I[Cancelled · days returned · approval withdrawn]
  G -- Cancel --> I
  G --> N[Employee notified: email + in-app]
  H --> N

• Working days exclude weekends (set in the company work schedule) and company holidays. A one-day request can be a half day.
• The request form shows how many days will be counted before you submit.
• A request crossing 31 December is split per year and each year’s balance is checked. Balances are created automatically from the hire date and renew each January.
• Some leave types need a supporting document, such as a medical certificate, and some can only be filed a few days after they started; HR can record older leave.
• Nobody can approve their own leave, and a manager cannot approve a request directly once its start date has passed; HR can.
• Cancelling a request withdraws it from the approver’s list and returns the days.

What happens when an approver does not act. Who takes part: Manager, HR Admin

flowchart LR
  A[Request enters a workflow step] --> B[Approver notified]
  B --> C{Decided within SLA?}
  C -- yes --> D[Next step or final decision]
  C -- no --> E[Hourly job: escalate]
  E --> F{Approver has a manager?}
  F -- yes --> G[Reassign to that manager]
  F -- no --> H[Reassign to an HR admin]
  G --> I[New approver notified]
  H --> I

• Each step has a deadline: 48 hours unless the workflow sets another one for that step.
• An overdue request moves to the approver’s manager, or to an HR admin when the approver has no manager, and the new approver is notified.
• Delegations redirect approvals while someone is away, including requests that were already waiting; ending a delegation returns them.
• An approver without a login, or who has left, is skipped and the request goes to HR so it is never stuck.

How a check-in is accepted, flagged or refused. Who takes part: Employee

flowchart TD
  A[Employee taps Check in] --> A2{Same punch in the last 60 s?}
  A2 -- yes --> OK0[Returns the same punch]
  A2 -- no --> A3{Approved full-day leave?}
  A3 -- yes --> X2[Refused: on leave]
  A3 -- no --> B{Month payroll finalized?}
  B -- yes --> X[Refused: period locked]
  B -- no --> C{Geofence policy}
  C -- off --> OK[Punch saved]
  C -- flag / block --> D{Location shared?}
  D -- no --> Y[Refused: location required]
  D -- yes --> E{Inside a work location radius?}
  E -- yes --> OK
  E -- no, flag --> F[Saved, marked outside fence for HR]
  E -- no, block --> Z[Refused: N m away from site]

• Lateness is judged against the assigned shift and its grace period, on the company’s own timezone.
• On a night shift, the morning punch closes the shift that started the evening before.
• Tapping Check in twice within a minute does not create a second punch, and you cannot check in on a day of approved leave.

An employee asks for a missed or wrong punch to be fixed and HR answers. Who takes part: Employee, HR Admin, Manager

flowchart LR
  A[Employee: Request correction with a note and proposed times] --> B[Pending · HR and line manager notified]
  B --> C{HR answers}
  C -- Approve --> D[Proposed times applied as manual punches]
  C -- Reject + reply --> E[Rejected with the reply]
  D --> F[Employee notified]
  E --> F

• HR approves the request, optionally with the corrected times, or rejects it with a reply.
• You are told the answer, and a month whose payroll is finalized cannot be changed.

From processing a month to payslips. Who takes part: Company Owner, HR Admin, Employee

flowchart LR
  A[Owner: Run Payroll for month] --> B[Draft run]
  B --> C[Review lines, fix errors, add adjustments]
  C --> D[Submit for approval]
  D --> E[Approved]
  E --> F[Finalize]
  F --> G[Payslips available + emailed]
  F --> H[Attendance for the month locked]
  F --> I[Claims reimbursed, instalments and advances deducted]
  F --> J[Bank file: WPS in Saudi Arabia, CSV in Egypt]
  D -. withdraw .-> B
  E -. reopen .-> B
  F -. void latest run .-> V[Voided: month can be processed again]

• Only the company owner can process, submit and finalize payroll; HR admins can open and review runs.
• Everyone employed in the month is included, with people on probation paid at the company’s probation percentage. Loan instalments, salary advances, approved expense claims and the employee’s insurance share are added automatically.
• Employees who cannot be calculated, for example with no salary, are listed with the reason and must be fixed before the run can be finalized. The owner can add bonuses, commissions or penalties to a line while the run is a draft.
• Large companies are calculated in the background; the page shows Calculating and updates by itself.
• Finalizing locks the month: payslips are sent, expense claims are reimbursed, loan instalments are deducted and the month’s attendance is locked.
• A mistake can be corrected: reopen a run that is not final, or void the latest finalized run and process the month again. Money already sent to the bank is not reversed.
• Finalized runs can be compared with each other.

Two-level approval to reimbursement. Who takes part: Employee, Manager, HR Admin

flowchart LR
  A[Draft] --> B[Submitted]
  B --> C[Manager approved]
  C --> D[Finance approved]
  D --> E[Reimbursed]
  B -. reject .-> R[Rejected]
  C -. reject .-> R

• Claims can be saved as a draft or submitted immediately.
• Once both approvals are done the claim is paid with the next payroll; it shows Reimbursed, and the employee is notified, when that month’s payroll is finalized.

From a requisition to a new employee. Who takes part: Manager, Recruiter, Candidate, HR Admin

flowchart TD
  A[Requisition] --> B{Approved?}
  B -- "no: edit and resubmit" --> A
  B -- yes --> C[Job posting published · closes after its end date]
  C --> D[Candidate applies on the careers page]
  D --> E[Applied → Shortlisted]
  E --> F[Interview scheduled → completed · marked or after 24 h]
  F --> G[Offer: approval → sent · e-signature or link]
  G --> H{Candidate decision}
  H -- accepts --> I[Convert to employee · requisition Filled]
  H -- declines --> J[Offer declined]
  G -. date passes .-> X[Offer expires · back to Interview Completed]
  G -. HR withdraws .-> W[Offer withdrawn · candidate emailed]
  E -. reject .-> K[Rejected · open interviews cancelled, open offers withdrawn · email]
  I --> L[Onboarding starts]

• Candidates confirm interviews and answer offers from a link in their email; they do not need an account.
• The pipeline follows what happens: scheduling and completing an interview and sending and answering an offer move the candidate for you, and every change is recorded with who made it.
• An offer that passes its date expires by itself; HR can edit a draft, withdraw a sent offer and send it again. If the offer is signed electronically, the signature accepts it.
• Rejecting a candidate cancels their open interviews and withdraws open offers; the rejection email never shows the internal reason.
• Converting an accepted offer creates the employee, closes the role’s postings and starts onboarding.

From first day to the probation decision. Who takes part: HR Admin, Manager, Employee

flowchart LR
  H[Employee added: form, import or converted candidate] --> A[Onboarding starts automatically from a matching template]
  A --> B[Tasks assigned to owners and notified]
  B --> C[Tasks completed / evidence]
  B -. nightly .-> O[Overdue marked]
  C --> D[Run completed]
  H --> P[Probation review created before the probation ends]
  P --> Q[Reporting-line manager recommends confirm, extend or end]
  Q --> R[HR confirms the decision]
  R -- Terminate --> T[Leaving today, access ends overnight]

• Onboarding starts by itself when an employee is added, from the template that fits them, and each task owner is notified.
• Probation reviews are created every morning before a probation ends; the review goes to the employee’s own manager, who recommends confirming, extending or ending probation. HR confirms the decision.
• An overdue review is escalated, and a probation that has already ended is still reviewed rather than confirmed automatically.

A leaver’s exit. Who takes part: HR Admin, Employee

flowchart LR
  T[Termination recorded: reason + last working day] --> A
  A[Start Offboarding: type + last day from the termination] --> B[Tasks with owners: general, IT access, asset return, final settlement]
  B --> C[IT access revoked on schedule]
  B --> D[Exit interview invitation]
  D -. daily .-> R[Reminders]
  B --> E{Termination recorded?}
  E -- yes --> F[Run closed]
  E -- no --> X[Cannot close]

• Offboarding can start before or after the termination is recorded and takes the last working day from it.
• Every task has an owner who is notified, and the leaver receives the exit-interview invitation and reminders.
• Access is removed after the last working day; a finance task lists any money owed or due, such as loan balances and unused leave.
• A run can be closed only once the termination is recorded.

Statuses an employee moves through. Who takes part: HR Admin

stateDiagram-v2
  [*] --> probation: added / hired
  [*] --> active: added
  probation --> active: probation confirmed
  active --> inactive
  inactive --> active: reactivated
  active --> scheduled: terminate (reason + last working day)
  probation --> scheduled: terminate
  inactive --> scheduled: terminate
  scheduled --> terminated: after the last working day (access ends, handover)
  scheduled --> active: rehire cancels it
  terminated --> active: rehire (termination reversed)

• An employee is Active, On probation, Inactive or Terminated.
• Terminating records a reason and a last working day. The employee keeps working and signing in until the end of that day; then they are marked Terminated, their access ends and their team and open approvals are handed over.
• Reactivating a former employee, or one whose termination has not taken effect yet, restores things as they were. Hire date and leave balances are kept for HR to adjust.

How a file becomes records. Who takes part: HR Admin

flowchart LR
  A[Choose module] --> B[Upload file]
  B --> C[Validating]
  C --> D[Ready for review]
  D --> E[Processing]
  E --> F[Completed]
  E --> G[Completed with errors]
  C --> H[Failed]

• Rows are checked before anything is saved, so you can review the file first. Rows that fail can be downloaded as a file, corrected and imported again.

What a new workspace contains. Who takes part: Company Owner

flowchart TD
  A[Owner completes /register: step 1 required, step 2 optional] --> B[Company on the Free plan, no card]
  B --> C[Owner account + employee record]
  B --> D[Departments for the industry]
  B --> E[Leave types + country holidays]
  B --> F[Standard roles]
  B --> G[General chat channel]
  B --> H[Onboarding, offboarding, review and document templates]
  C --> I[Signed in → setup checklist]

• The setup checklist asks to add employees, review leave types, invite an HR teammate and review departments.
• The first step asks for the country, Egypt or Saudi Arabia, which sets the public holidays, leave rules and payroll defaults, and for acceptance of the Terms of Service and the Privacy Policy.
• New owners confirm their email before they can pay or invite people.