# SecureForce documentation (all pages) # SecureForce documentation > What SecureForce does, who it is for, and where to start reading. SecureForce runs the workforce of a security or facility-management company: the guards, housekeeping staff, technicians and supervisors you post at your customers' sites. It covers the whole life of a worker: 1. **Hire and verify**: add people one by one or from a spreadsheet, collect and verify their documents, run the pre-hire KYC checks. 2. **Post them at a site**: deploy each person to a customer's site in a role, with a pay rate and a bill rate, and put them on shifts. 3. **Capture attendance**: guards check in and out on their own phone, with a photo and a location check against the site's boundary. 4. **Report and get paid**: the daily report (DMR) shows each customer approved vs deployed vs present staff; payroll and billing are generated from the same attendance. **New to SecureForce? Start with the [Quickstart](/docs/quickstart):** a step-by-step walkthrough, with a picture of every screen, from signing up to a worker checking in at a customer's site. ## Who these docs are for - **Admins and operations staff** setting SecureForce up for the first time: start with [Quickstart](/docs/quickstart). - **HR** hiring and verifying staff: [Employees](/docs/employees), [Document rules](/docs/document-rules), [Onboarding](/docs/onboarding), [KYC verification](/docs/kyc), [HR approval](/docs/hr-approval), [Approve & Deploy](/docs/approve-and-deploy). - **Supervisors** running a site day to day: [Field Attendance](/docs/field-attendance), [Leave](/docs/leave). - **Payroll and finance**: [Finance, from attendance to cash](/docs/finance) (the monthly cycle, step by step), then [Payroll and billing](/docs/payroll-and-billing) for the calculations. - **Customers** with their own login: [Daily report](/docs/daily-report), [Client portal](/docs/client-portal). - **AI assistants and automation**: [Agent guide](/docs/agent-guide), plus the plain-text versions below. ## How the docs are organised | Section | What's in it | |---|---| | Getting started | This page, the [Quickstart](/docs/quickstart), [Core concepts](/docs/core-concepts) (how the modules depend on each other) and [Roles and access](/docs/roles-and-access). | | Set up | Things done once: [workspace](/docs/workspace), [organization](/docs/organization), [clients and sites](/docs/clients-and-sites), [administration](/docs/administration). | | People | [Employees](/docs/employees), [onboarding](/docs/onboarding), [KYC](/docs/kyc). | | Operations | [Deployment](/docs/deployment), [shifts and roster](/docs/shifts-and-roster), [Field Attendance](/docs/field-attendance), [leave](/docs/leave). | | Customers | [Daily report (DMR)](/docs/daily-report), [client portal](/docs/client-portal). | | Finance | [Finance, from attendance to cash](/docs/finance) (payroll, invoices, payments, receivables, reconciliation, profitability, overview) and [payroll and billing](/docs/payroll-and-billing). | | Oversight | [Compliance](/docs/compliance), [dashboard, notifications and reports](/docs/dashboard-and-reports). | | Office IT | [Activity tracking and software security](/docs/activity-tracking), [remote lock and Lost Mode](/docs/remote-lock-and-lost-mode). | | Reference | [Routines](/docs/routines), [troubleshooting](/docs/troubleshooting), [glossary](/docs/glossary), [agent guide](/docs/agent-guide). | ## Plain-text versions for LLMs Every page is also available as plain Markdown, so you can paste it into an AI assistant or let one fetch it: - [/llms.txt](/llms.txt): an index of every page with a one-line summary. - [/llms-full.txt](/llms-full.txt): all pages in one file. - `/docs/md/.md`: one page, e.g. [/docs/md/field-attendance.md](/docs/md/field-attendance.md). Each page here also has **Copy page** and **View as Markdown** buttons at the top. ## Conventions used in these docs - **Bold text** is the exact label of a button, tab, field or menu item in the app. - **Screenshots** have numbered labels. A **red** label is something you do (click, type or choose), in number order. A **blue** label is something to look at. Click a screenshot to open it full size. - "Sidebar → **Employees**" means: click **Employees** in the left sidebar. - The order of the setup pages matters. Each step relies on the ones before it; [Core concepts](/docs/core-concepts) shows the chain. --- # Quickstart > A step-by-step walkthrough with a picture of every screen, from signing up to a new worker checking in at a customer's site and showing on the daily report. This is the shortest path from signing up to seeing a new guard's check-in on the customer's daily report. **Do the steps in this order**, because each one needs the ones before it. Every step shows the screen and links to the full page for that feature. **Reading the screenshots:** a **red** numbered label is something you do (click, type or choose), in number order. A **blue** label is something to look at. Click any screenshot to open it full size. ## 1. Sign up Open SecureForce, go to **Sign up**, and enter your name, your **organisation name** (e.g. *Paradigm IFM*), work email and a password. Press **Create workspace admin**. You become the **Admin** of a workspace named after your organisation. ![Sign up](/docs-images/guide/sign-up.webp) The workspace starts as **Approval Pending** until the SecureForce team approves it. The page moves on by itself once approved, or press **Check status**. ![Approval Pending](/docs-images/guide/approval-pending.webp) More: [Workspace](/docs/workspace). ## 2. Find your way around Every module is in the left menu. At the top: the workspace you're in, the site picker (**All sites** or one site), notifications, and **Docs & help** for these pages. ![The screen: (1) menu, (2) workspace, (3) site picker, (4) alerts, (5) help](/docs-images/guide/dashboard-tour.webp) More: [Dashboard and reports](/docs/dashboard-and-reports). ## 3. Describe your company Sidebar → **Organization**: add your **branches** (e.g. *Bengaluru East*), and if you use them, companies, departments, service lines and grades. ![Organization: Add branch](/docs-images/guide/organization.webp) More: [Organization](/docs/organization). ## 4. Give your team their logins Sidebar → **Administration** → **Workspace Members** → **Add member**. Supervisors and guards can sign in with their **mobile number**; pick their **role**, press **Generate** for a password, then **Add member**, and share the details yourself (no email is sent). ![Add member with a mobile number](/docs-images/guide/add-member.webp) A supervisor should only see their own site: give them a **site** data scope. Guards get their login later (step 13), once their employee record exists. More: [Administration](/docs/administration). ## 5. Add the customer and their sites Sidebar → **Clients & Sites** → **Set up a customer**. One wizard creates the customer group, its companies, contracts, sites (with the gate location and boundary) and the **approved headcount** per designation, the daily report's *Total approved*. ![Clients & Sites: Set up a customer](/docs-images/guide/setup-button.webp) ![A site with its boundary and approved headcount](/docs-images/guide/step4-site.webp) More: [Customer setup](/docs/customer-setup), [Clients and sites](/docs/clients-and-sites). ## 6. Set the attendance rules Sidebar → **Field Attendance** → **Setup**: the **Location check** (**Enforce** refuses check-ins outside the boundary), **Late after**, and **Photo at check-in and check-out**. Press **Save rules**. The approved headcount per site is on the right if you need to change it. ![Field Attendance → Setup](/docs-images/guide/attendance-setup.webp) More: [Field Attendance](/docs/field-attendance#attendance-rules). ## 7. Create the shifts Sidebar → **Attendance** → **Add shift**: name (*Day*), start and end time, break minutes, status **Published**. ![Add shift](/docs-images/guide/shift-add.webp) More: [Shifts and roster](/docs/shifts-and-roster). ## 8. Add the new worker Sidebar → **Employees** → **Add employee**. Name, **mobile number** and an emergency contact are required. Many workers at once? Use **Bulk Onboarding** with a spreadsheet. ![Add employee](/docs-images/guide/add-employee.webp) More: [Employees](/docs/employees). ## 9. Verify them (KYC) Sidebar → **KYC Verification** → **Start a KYC case** → pick the worker → **Open case**. Sign off each check (Aadhaar and PAN can come from **DigiLocker**), add previous employers, then **Clear for deployment**. ![A KYC case with every check verified](/docs-images/guide/kyc-all-verified.webp) More: [KYC verification](/docs/kyc). ## 10. Collect their documents First time only: Sidebar → **Document Rules** → **Add the standard categories**, then add which documents each category needs (e.g. PSARA training and police verification for Security Guards). Then on the worker's **Onboarding** page, **Document Upload**: choose their category and designation, upload each required document, and verify it. A document that isn't available yet can be **Waived** with a reason. ![The worker's required documents](/docs-images/guide/required-list.webp) More: [Document rules](/docs/document-rules), [Onboarding](/docs/onboarding). ## 11. HR approves them First time only: Sidebar → **Salary Structures** → **Add salary structure** for each role. Then Sidebar → **HR Approval & Deploy** → open the worker. When every check is green, pick the salary structure and **Prepare approval and contract**. Hand the phone to the worker to **sign the contract**, then press **Approve**. ![Prepare the approval and contract](/docs-images/guide/prepare.webp) ![The worker signs the contract](/docs-images/guide/contract-sign.webp) More: [HR approval](/docs/hr-approval). ## 12. Approve & Deploy On the same page: pick the **site**, the **designation**, the **shift** and the **weekly off** (or **Reliever / floater**), take a **face photo**, and press **Approve & Deploy**. If the site's contract needs the client's NDA, the worker signs it first. One click creates the deployment, rosters the worker, registers their face, and starts payroll and billing. ![Approve & Deploy](/docs-images/guide/deploy-form.webp) More: [Approve & Deploy](/docs/approve-and-deploy). ## 13. The guard checks in First give the guard a login: **Administration** → **Add member**, role **Field Employee**, the **same mobile number** as on their employee record. The result must say **Linked to their employee record**. Then on the guard's phone: open SecureForce, sign in with the mobile number and password, and allow camera and location. At the site, press **Check in**, take the photo, press **Use photo**. The screen shows **Present** (or **Late**). ![Check in on the phone](/docs-images/guide/guard-check-in.webp) A guard with no smartphone? The supervisor checks them in from **Muster → Check in a guard**. More: [Field Attendance](/docs/field-attendance). ## 14. See it everywhere - **Field Attendance → Today**: approved, deployed, present and shortage, for every site. - **Field Attendance → Muster**: each person's photo, time and distance from the site; mark, correct and **Approve day**. - **Daily Report (DMR)**: the report the customer gets. Download it as Excel. - **Client Portal**: what the customer sees with their own login. - At month end, **Payroll Prep** and **Billing Prep** → **Generate**. ![Today](/docs-images/guide/today.webp) ![The daily report](/docs-images/guide/dmr.webp) Next: read [Core concepts](/docs/core-concepts) to understand why each step was needed. --- # Core concepts > The records SecureForce is built on and how they connect, from workspace to employee to deployment to roster to attendance to reports, payroll and billing. Most "why don't I see…" questions come from one missing link in a chain. This page explains the chain. ## The chain ``` Organization (company, branch, grade) Clients & Sites (site point + radius) │ │ ▼ │ Employee ──(same email)──► Login (Field Employee) │ │ Onboarding + KYC │ │ │ ▼ ▼ Deployment (employee + client + site + role title + start date + pay rate + bill rate) │ ▼ Roster assignment (employee + deployment + shift + site + date) │ ▼ Check-in on the phone (photo + location vs the site's boundary) │ ▼ Attendance record (present / late / half day / absent / leave / holiday / weekly off) │ ├──► Daily report (DMR): approved headcount vs deployed vs present, per designation ├──► Payroll Prep: days × deployment pay rate (+ overtime) ├──► Billing Prep: days × deployment bill rate, per client and site └──► Client Portal and Reports ``` ## The records | Record | What it is | Created in | Needed by | |---|---|---|---| | Workspace | One organisation's private space. Nothing crosses between workspaces. | Sign up / workspace switcher | Everything | | Company, branch, department, service line, grade | Your own company's structure. | Organization | Employees, deployments | | Client | A customer you supply staff to. | Clients & Sites | Sites, deployments, billing | | Site | A place where staff work, with latitude, longitude and a geofence radius. | Clients & Sites | Deployments, rosters, check-in | | Employee | One record per person. Its **email** links it to a login. | Employees, bulk onboarding | Everything about that person | | Login (member) | A user account in the workspace with a role. | Administration → Add member | Signing in | | KYC case | The pre-hire checks for one candidate. | KYC Verification | Deployment readiness | | Onboarding case | The six-step checklist for one person. | Employee profile → Start onboarding | Deployment readiness | | Deployment | A person posted at a site in a role, from a **start date**, with a **pay rate** and **bill rate**. | Onboarding step 6, Deployment, bulk onboarding | DMR "Deployed", payroll, billing | | Shift | A time slot (Day 07:00–19:00, Night…). | Attendance | Roster | | Roster assignment | One person on one shift at one site on one date, ideally linked to their deployment. | Attendance | The guard's check-in screen, muster, payroll link | | Attendance record | What actually happened that day: check-in/out times, photo, distance, status. | The guard's phone, or the muster | DMR, payroll, billing, reports | | Approved headcount | How many people of each designation the contract allows at a site. | Field Attendance → Setup | DMR "Total approved" and shortage | | Data scope | A limit on what one login can see (a branch, client, site or employee). | Administration → Data Scopes | Supervisors, customers | ## Rules that catch people out 1. **The employee's email must match the login's email exactly**, and only one employee may have it. Otherwise the person sees "Your account is not linked to an employee record". 2. **No roster for today means no check-in.** The phone reads today's roster to know the site and shift. 3. **The deployment's role title must match the approved headcount's designation** (e.g. both *Security Guard*). Otherwise the DMR shows the person under "Cover from another post" or "Unassigned role". 4. **A deployment counts as deployed from its start date.** New deployments start today unless you set a date. 5. **Payroll and billing follow attendance → roster → deployment.** If the roster entry isn't linked to a deployment, or the deployment has no rate, the days are counted at ₹0 and flagged. 6. **Without a data scope, a role sees the whole workspace.** Supervisors and customers should always be scoped. 7. **Approved days are locked.** Approve a day in the muster once it is correct; locked payroll periods can't be regenerated. ## Statuses at a glance | Record | Statuses | |---|---| | Employee | candidate, onboarding, active, on leave, suspended, terminated | | Onboarding | draft, in progress, blocked, completed, cancelled | | Document | pending, submitted, verified, rejected, expired | | KYC case | draft, in review, on hold, cleared, rejected | | KYC check | not started, in progress, verified, failed, waived | | Deployment | planned, active, completed, cancelled | | Shift | draft, published, locked, cancelled | | Attendance | present, late, half day, absent, leave, holiday, weekly off, exception | | Leave request | requested, approved, rejected, cancelled | | Payroll input | draft, approved, exported, locked | | Billing input | draft, approved, invoiced, locked | | Compliance task | open, in progress, completed, overdue, waived | --- # Roles and access > The eight roles, the permissions each one holds, and how data scopes limit what a login can see. Every login in a workspace has one **role**. The role decides which modules appear in the sidebar and what the person can change. A **data scope** can then narrow which branches, clients, sites or employees they see. ## Roles | Role | Typical person | Can do | | ------------------ | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Admin** | Owner, head of operations | Everything, including logins, roles, scopes, settings and software policy. | | **Ops Manager** | Operations manager | Employees, deployments, rosters, attendance, leave, billing, compliance, client service requests, master data (clients, sites, organization). | | **HR Manager** | HR team | Employees, onboarding, documents, consents, verifications, KYC, deployments, leave, payroll, compliance. | | **Supervisor** | Site supervisor | Attendance and rosters, leave and compliance for their scoped site(s): run the muster, mark and correct attendance. | | **Field Employee** | Guard, housekeeping, technician | Their own check-in and check-out on the phone; their own roster, attendance and leave. | | **Client** | The customer's facility manager | The Daily Report, Client Portal, read-only billing and invoices, and compliance items for their own sites, and their own customer group and contracts. | | **IT Admin** | IT team | Logins, devices, activity tracking and software security. | | **Viewer** | Auditor, management | Read-only access across the workspace. | ## Permissions by role These are the permission codes each role holds. A page or button that needs a permission is hidden or disabled without it. | Permission | Admin | Ops Manager | HR Manager | Supervisor | Client | IT Admin | | ------------------------------------------------- | ----- | ----------- | ---------- | ---------- | ------ | -------- | | tenant.manage (workspace settings, scopes) | ✓ | | | | | ✓ | | identity.manage (logins and members) | ✓ | ✓ | ✓ | | | ✓ | | audit.read (audit log) | ✓ | ✓ | ✓ | | | ✓ | | master_data.manage (organization, customer groups, clients, contracts, sites) | ✓ | ✓ | | | | | | employees.manage | ✓ | ✓ | ✓ | | | | | onboarding.manage | ✓ | | ✓ | | | | | documents.manage (incl. document rules and waivers) | ✓ | | ✓ | | | | | consents.manage / verifications.manage | ✓ | | ✓ | | | | | kyc.manage | ✓ | | ✓ | | | | | onboarding.manage also covers HR approval (prepare, approve, collect signatures) | ✓ | | ✓ | | | | | payroll.manage also covers the salary table | ✓ | | ✓ | | | | | deployments.manage (incl. Approve & Deploy and client NDAs) | ✓ | ✓ | ✓ | | | | | rosters.manage | ✓ | ✓ | | ✓ | | | | attendance.manage | ✓ | ✓ | | ✓ | | | | leave.manage | ✓ | ✓ | ✓ | ✓ | | | | payroll.manage | ✓ | | ✓ | | | | | billing.manage | ✓ | ✓ | | | | | | billing.period.unlock | ✓ | | | | | | | billing.manual.review | ✓ | ✓ | | | | | | compliance.manage | ✓ | ✓ | ✓ | ✓ | | | | service_requests.manage | ✓ | ✓ | | | | | | software.manage (software security) | ✓ | | | | | ✓ | Field Employee and Viewer hold no manage permissions. A Field Employee can still read and act on their own records, such as their roster, their attendance and their check-ins. **Administration → Role Permissions** shows this list for your workspace. ## Data scopes A scope limits one member to part of the workspace. Set it in **Administration → Data Scopes → Assign scope**: choose the **Member**, the **Scope type** and the **Scope target**, then press **Assign**. | Scope type | The member sees | | ---------- | --------------------------------------------------- | | all | Everything (same as no scope) | | branch | Sites and people serviced by that branch | | client | That customer's sites and the people deployed there | | site | One site | | employee | One employee's records | Always scope **Supervisors** (to their site or sites) and **Clients** (to their client). Without a scope, a role sees the whole workspace. ## Privacy defaults - Aadhaar numbers are masked to the last four digits everywhere, including for admins. - Every create, change and delete is written to the audit log (**Administration → Recent Audit Activity**). - Customer logins don't see identity documents, bank details or police records. --- # Workspace > Sign up, create and switch workspaces, and find your way around the screen. A **workspace** is one organisation's private area. Employees, customers, attendance and settings all belong to one workspace and are never visible from another. A person can belong to several workspaces and switch between them. ## Sign up as the first admin Open SecureForce and click **Sign in** at the top right of the home page. ![The SecureForce home page, with Sign in at the top right](/docs-images/guide/landing.webp) 1. Go to the **Sign up** tab (route `/auth`). 2. Enter **Full name**, 3. **Organisation name**, 4. **Work email**, 5. and a **Password** (at least 8 characters). 6. Press **Create workspace admin**. ![The Sign up form](/docs-images/guide/sign-up.webp) Your workspace is created, named after your organisation, with the status **Approval Pending**. Until the SecureForce team (IVT) approves it you see an *Approval pending* page with your organisation, email and when you registered; every other page sends you back there. The page checks again by itself every 30 seconds, or press **Check status**. ![Approval Pending](/docs-images/guide/approval-pending.webp) Once approved you land on the **Dashboard** as the **Admin**. If the registration is **Rejected**, the page shows the reason SecureForce gave; contact SecureForce support to have it reviewed again. ![The first Dashboard of a new workspace](/docs-images/guide/first-dashboard.webp) Nobody else needs to sign up: you add every other person from [Administration](/docs/administration), and they are not held for approval. ### Approval by SecureForce (Super Admin Console) SecureForce staff with super admin access sign in at the same address and land on the **Super Admin Console** (`/super-admin`). It lists every registration with the organisation, the org admin's name, email and phone, and when they registered, under **Pending**, **Approved** and **Rejected** tabs. - **Approve**: the org admin can use SecureForce straight away. - **Reject**: a reason is required; the org admin sees it. A rejected registration can still be approved later from the **Rejected** tab. ![The Super Admin Console: (1) the new registration, (2) Approve](/docs-images/guide/super-admin.webp) Super admin access is granted by SecureForce engineering in the database (`public.platform_admins`); it can't be granted from inside the app. A super admin who also belongs to a workspace sees a **Super Admin** button in the top bar. ## Sign in The first box takes either an email or a mobile number: guards an admin added by mobile number type their number there, with their password. You can also use **Continue with Google**. Someone added by email can also type the mobile number on their employee record instead, with the same password: it is the same account. ![Signing in: (1) email or mobile number, (2) password, (3) Sign in](/docs-images/guide/sign-in.webp) **Forgot password?** No reset emails are sent yet, so this explains how to get a new password from your workspace admin, who resets it from **Administration → Workspace Members → Reset password** and shares it with you. Change it afterwards from your [Profile](/docs/dashboard-and-reports#profile). ## Create a properly named workspace 1. Click the **workspace switcher** in the top bar (it shows the current workspace's name). 2. Choose **Create workspace**. 3. Enter the **Workspace name** (e.g. *Paradigm IFM*) and the **Country code** (default **IN**). 4. Press **Create workspace**. You are switched into it and taken to the Dashboard. Only admins can create further workspaces. ## Switch workspace Click the workspace switcher and pick another workspace. The page reloads with that workspace's data; your choice is remembered next time you sign in. ![The workspace switcher](/docs-images/guide/workspace-switcher.webp) ## Find your way around ![The screen: (1) menu, (2) workspace, (3) site picker, (4) alerts, (5) help](/docs-images/guide/dashboard-tour.webp) 1. **Left sidebar**: every module you have access to, grouped as Overview, Workforce, Clients, Finance, Insight and Governance. Items you can't use are hidden. The button at the top left collapses it to icons. 2. **Workspace switcher**: the workspace you're in. 3. **Site picker** (**All sites**): limit every page to one site. You only see the sites your login covers; see [Data scopes](/docs/roles-and-access#data-scopes). 4. **Notifications** (the bell): items that need attention. 5. **Docs & help**: these pages. The top bar also has search (employees, sites, leave, payroll, billing…), light/dark mode and your name. Click your name for [Profile](/docs/dashboard-and-reports#profile), or use the arrow to sign out. ![The site picker](/docs-images/guide/site-switcher.webp) **Install as an app**: on a phone, Chrome menu → **Install app** / **Add to Home screen** (iPhone Safari: Share → **Add to Home Screen**). SecureForce then opens full-screen like a normal app. This is recommended for guards. ## Next [Organization](/docs/organization): describe your own company. --- # Organization > Set up your own company's structure (vendor companies, branches, departments, service lines and employee grades with their pay currency), which every employee and deployment refers to. Sidebar → **Organization** (route `/organization`). This describes **your** company, the service provider, not your customers. You set it up once; each list then becomes a dropdown on employees, deployments and payroll. **Who can do this:** Admin, Ops Manager (permission `master_data.manage`). ## The five lists Each list has its own **Add** button, an **Edit** and **Delete** per row, and a **Status** (active, inactive, archived). Codes are generated automatically from the numbering set in [Administration](/docs/administration#numbering). ![Organization: (1) the menu item, (2) Add branch](/docs-images/guide/organization.webp) ### Vendor companies → Add company A **vendor company** is your own legal entity: the company that employs your staff and sends them to customers' sites (in this app you are the vendor, your customers are the clients). Everything you hire and deploy sits under one. ![Add company: (1) trading name, (2) name as registered, (3) GSTIN, (4) PAN, (5) Save](/docs-images/guide/org-company-add.webp) | Field | Required | Notes | |---|---|---| | Company name | Yes | Trading name, e.g. *Paradigm Integrated Facility Management* | | Legal name | | As registered | | GSTIN | | 15 characters | | PAN | | | | Code | | Generated (COM-0001) when created; branch, department, service line and grade codes work the same way. Editing a record keeps its code. | Add one per legal entity if your group has several, e.g. a security company and a facility-management company under the same owners. Each has its own GSTIN, PAN and code. ![Vendor companies: the new company with its code, GSTIN and PAN; (1) Add company](/docs-images/guide/org-companies.webp) **Edit** on a row changes the company; **Delete** removes it. A company that branches or employees still point to should be set to **inactive** instead of deleted. ### Branches → Add branch | Field | Required | Notes | |---|---|---| | Company | | Which company the branch belongs to | | Branch name | Yes | e.g. *Bengaluru*, *Hyderabad*, *Pune* | | Region | | e.g. *South* | ![Add branch: (1) name, (2) region, (3) Save](/docs-images/guide/add-branch.webp) A branch is an office that services a set of sites. A site's **Servicing branch** and a **branch** data scope refer to it. ### Departments → Add department **Department name** (required), e.g. *Operations*, *HR*, *Finance*. The code (DEP-001) is generated. ![Add department: (1) the name, (2) Save](/docs-images/guide/org-department-add.webp) ![Departments: (1) Add department](/docs-images/guide/org-departments.webp) ### Service lines → Add service line **Service line** (required) and a **description**: what you sell, e.g. *Manned guarding*, *Housekeeping*, *Technical (MEP)*. Deployments can name a service line. ![Add service line: (1) what you sell, (2) a short description, (3) Save](/docs-images/guide/org-service-line-add.webp) ![Service lines: (1) Add service line](/docs-images/guide/org-service-lines.webp) ### Employee grades → Add grade | Field | Required | Notes | |---|---|---| | Grade name | Yes | e.g. *Security Guard*, *Supervisor* | | Grade code | | Generated (GRD-01) when created | | Currency | | The currency the pay below is in. Default **INR (₹)**; also AED, SAR, QAR, OMR, KWD, BHD, USD, EUR, GBP, SGD and more | | Base pay | | Monthly, e.g. 18000 | | Overtime rate | | Per hour, e.g. 120 | | Status | | active / inactive / archived | ![Add grade: (1) name, (2) currency, (3) monthly pay, (4) overtime per hour, (5) Save](/docs-images/guide/org-grade-add.webp) The list shows each grade's pay in its own currency, so a grade for staff posted in Dubai can be set in dirhams next to your rupee grades: ![Employee grades: ₹ and AED grades side by side; (1) Add grade](/docs-images/guide/org-grades.webp) Each employee is given a grade. Grades created before the currency option existed are in INR. ## How it connects - [Employees](/docs/employees) pick a company, branch, department and grade. - [Deployments](/docs/deployment) carry the company and branch, and optionally a service line. - [Clients and sites](/docs/clients-and-sites): a site's **Servicing branch** comes from here. - [Company Overview](/docs/dashboard-and-reports#company-overview) lists each company with its people. ## Next [Clients and sites](/docs/clients-and-sites). --- # Clients and sites > Add the customers you supply staff to and the sites where your staff work, including the GPS point and geofence radius used for the attendance location check. Sidebar → **Clients & Sites** (route `/clients-sites`). A **client** is a company you bill, such as a residents' association or one company of a corporate group. A **site** is a place where your staff work for that client: a building, a gate or a campus. One client can have many sites. Above clients sit **customer groups** (a customer with several sister companies), and between clients and sites sit **contracts** (one contract can cover several sites): **Customer group** › **Client (company)** › **Contract** › **Site** Both are optional: a single residents' association needs neither. **Who can do this:** Admin, Ops Manager (permission `master_data.manage`). > **New customer?** Use **Set up a customer** at the top of the page. It creates the group, companies, contracts, sites and approved headcount in one go — see [Customer setup](/docs/customer-setup). The lists below are for adding to or editing a customer afterwards. ## Customer groups **Customer groups → Add customer group**: a **Group name** (unique in the workspace), an optional **Group code** and **Notes**. A group that still has clients can't be deleted; move its clients to another group, or none, first. Use a group when one customer has several sister companies that you bill separately, e.g. *ABC Group* with *ABC Tech Pvt Ltd* and *ABC Realty LLP*. You then pick the group on each of those clients. ![Add customer group: (1) the group name, (2) an optional code, (3) notes, (4) Save](/docs-images/guide/cs-group-add.webp) ![Customer groups: (1) Add customer group](/docs-images/guide/cs-groups.webp) ## Contracts **Contracts → Add contract**: | Field | Required | Notes | |---|---|---| | Company | Yes | The client that holds the contract | | Contract name | Yes | e.g. *FM Contract 2026*. Unique per client | | Contract / PO number | | Unique in the workspace | | Status | | draft / active / expired / terminated | | Starts on / Ends on | | The end can't be before the start | | Client NDA required | | Whether workers at these sites sign the client's NDA | | Scope / notes | | | ![Add contract: (1) the company that holds it, (2) contract name, (3) PO number, (4–5) start and end, (6) client NDA, (7) Save](/docs-images/guide/cs-contract-add.webp) The list shows each contract's company, period, whether the client NDA is required, and status: ![Contracts: (1) Add contract](/docs-images/guide/cs-contracts.webp) On a site, pick the contract under **Contract (of the same client)**. A contract that sites are still under can't be deleted, and can't move to another company. Take the sites off it first (edit each site). ## Add a client **Clients → Add client**: ![Add client: (1) the customer's name, (2) Save](/docs-images/guide/client-add.webp) The **Clients** list shows each client's code, its customer group (or *Standalone*), industry and GSTIN: ![Clients: two companies under ABC Group, the rest standalone; (1) Add client](/docs-images/guide/cs-clients.webp) | Field | Required | Notes | | -------------------------- | ---------- | ----------------------------------------------------------- | | Client name | Yes | e.g. _Urban Greens Villa Owners Welfare Association_ | | Client code | | Generated (CLI-0001) when created; editing the client keeps it | | Customer group | | The group this company belongs to. Empty for a standalone customer | | Industry | | e.g. _Residential community_ | | GST registration | | registered / unregistered. Registered clients need a GSTIN. | | GSTIN | Registered | 15-character GSTIN; validated before saving | | Default GST treatment | | intra-state, inter-state, exempt, nil or not configured | | Place of supply state code | Taxable | Two-digit GST state code, e.g. `27` | | Status | | active / inactive / archived | Client GST data is used with the supplier **Billing Profile**. The client's explicit treatment wins over the tenant default, so an exempt or nil client can be billed without GSTIN, place-of-supply or supplier-state details. Taxable invoices are blocked until the client and supplier records are complete. ## Add a site **Client sites → Add site**, or **Edit** on a site's row to change it: ![Client sites: (1) Add site, (2) Edit a site](/docs-images/guide/sites-list.webp) | Field | Required | Notes | |---|---|---| | Client | Yes | The customer this site belongs to | | Contract | | A contract **of the same client**. Choosing another client's contract is refused | | Servicing branch | | The branch that runs it ([Organization](/docs/organization)) | | Site name | Yes | e.g. *Urban Greens Villas* | | Site code | | Generated (CLS-0001) when created; editing the site keeps it | | Site location | | Search / current location / map, which fills Latitude and Longitude (below) | | Latitude | For attendance | The main gate, decimal degrees, e.g. 12.9716 | | Longitude | For attendance | e.g. 77.5946 | | Geofence radius (metres) | | e.g. 200. Drawn as a ring on the map. Without one, the workspace default from Field Attendance → Setup applies. | | Status | | active / inactive / archived | | Field | Required | Notes | | ---------------- | -------------- | ---------------------------------------------------------------------------------------------- | | Client | Yes | The customer this site belongs to | | Servicing branch | | The branch that runs it ([Organization](/docs/organization)) | | Site name | Yes | e.g. _Urban Greens Villas_ | | Site code | | Generated (CLS-0001) | | Latitude | For attendance | The main gate, decimal degrees, e.g. 12.9716 | | Longitude | For attendance | e.g. 77.5946 | | Geofence radius | | In metres, e.g. 200. Without one, the workspace default from Field Attendance → Setup applies. | | Status | | active / inactive / archived | **Getting latitude and longitude** — the **Site location** box works like sharing a location on WhatsApp. Any of these fills **Latitude** and **Longitude** for you: - **Search**: type a place, landmark or address and pick it from the list. You can also paste a `lat, lng` pair (e.g. from Google Maps) and press Enter. - **Use current location**: while standing at the gate, press it and allow location when the browser asks. It shows how accurate the reading was. - **Map**: tap the map or drag the green pin onto the exact gate. The address under the map shows where the pin is. You can still type the numbers into **Latitude** and **Longitude** by hand; the pin follows what you type. Place search and the map use OpenStreetMap. ![A site's location: (1) search, (2) use current location at the gate, (3) the boundary in metres; the green ring shows it](/docs-images/guide/site-location.webp) **The location check depends on this.** A guard's phone measures its distance from this point. Within the radius the guard can check in; outside it, the check-in is flagged or refused, depending on the rule in [Field Attendance](/docs/field-attendance#attendance-rules). A site without latitude and longitude can't be checked. ## Good to know - If a client you just added isn't in the **Client** dropdown of **Add site**, reload the page. Dropdown lists load when the page opens. - Set the **approved headcount** for each new site in Field Attendance → Setup, or the daily report has nothing to measure shortage against. - Give the customer a login scoped to this client so they can see their own daily report ([Administration](/docs/administration#limit-what-someone-can-see-data-scopes)). That login also sees the client's own group and contracts, and nothing of other customers. - The **Customer groups** and **Contracts** lists appear once the database has been updated for them; until then the page shows Clients and Client sites as before. ## How it connects - [Deployments](/docs/deployment) and [roster assignments](/docs/shifts-and-roster) name a client and site. - [Field Attendance](/docs/field-attendance) checks location against the site. - The [daily report](/docs/daily-report) and [billing](/docs/payroll-and-billing) are per client and site. - The [client portal](/docs/client-portal) shows a customer their sites. --- # Customer setup > Set up a whole customer in one go — customer group, sister companies, contracts, sites and approved headcount — saved together or not at all. Clients & Sites → **Set up a customer** (route `/customer-setup`). A five-step wizard that creates everything a new customer needs, in the order the business is organised: **Customer group** › **Sister companies** › **Contracts** › **Sites** › **Approved headcount per designation** For example: *ABC Group* › *ABC Tech Pvt Ltd* › *FM Contract 2026* › *Whitefield Campus* › *Security Guard 6, Electrician 2*. A residents' association is the same path without a group: *Urban Greens Villa Owners Welfare Association* › *FM Contract 2026* › *Urban Greens Villas*. **Who can do this:** Admin, Ops Manager (`master_data.manage`). Approved headcount also needs `deployments.manage`; without it the sites are created and the headcount is left for an Ops Manager. ## How the pieces fit | Level | What it is | Where it lives afterwards | |---|---|---| | Customer group | The customer organisation. Optional. | Clients & Sites → **Customer groups** | | Company | A billed entity with its own GSTIN — a *sister company* when it is in a group. Each one is a **client**. | Clients & Sites → **Clients** | | Contract | An agreement held by **one** company. One contract can cover several sites. Optional. | Clients & Sites → **Contracts** | | Site | A building, gate or campus of one company, optionally under one of **that company's** contracts | Clients & Sites → **Client sites** | | Approved headcount | The contract number per designation at a site — the daily report's **Total approved** | Field Attendance → Setup, and the [daily report](/docs/daily-report) | ## The steps ![Clients & Sites: (1) the menu item, (2) Set up a customer](/docs-images/guide/setup-button.webp) The five steps are listed on the left; click any of them to go back. Nothing is saved until the last step. ### 1. Customer *New customer group*, an *Existing group* (to add more companies, contracts or sites to it), or *No group* for a single company. ![Step 1: (1) New customer group, (2) the group name, (3) Continue](/docs-images/guide/step1-group.webp) ### 2. Companies *Add new company* (name, GSTIN, industry, billing address, primary contact) or *Add existing company*. Removing a company also removes its contracts and sites from this setup. ![Step 2: (1) one per sister company, (2) name, (3) GSTIN, (4) contact person](/docs-images/guide/step2-companies.webp) Every step is checked as you go: **Continue** shows what needs fixing before moving on. Here the GSTIN was too short: ![A mistake caught before saving](/docs-images/guide/step2-mistake.webp) ### 3. Contracts Optional. Name (e.g. *FM Contract 2026*), contract or PO number, status, start and end dates, and whether the **client NDA** is required. Moving a contract to another company takes its sites with it. ![Step 3: (1) Add contract, (2) the company that holds it, (3) dates, (4) client NDA](/docs-images/guide/step3-contracts.webp) ### 4. Sites & headcount Company, contract (only that company's contracts are offered), site name, servicing branch, address, gate location and geofence radius (the same map as [Clients and sites](/docs/clients-and-sites#add-a-site)), and the **approved headcount** per designation. Designations already used in the workspace are suggested as you type; spell them the same way every time, because the daily report matches them by name. ![Step 4: (1) site name, (2) contract, (3) boundary, (4) Add designation and the approved number](/docs-images/guide/step4-site.webp) ### 5. Review Everything that will be created, grouped by company and contract, with any problems listed. Click a problem to jump to it. **Create customer** saves it all. ![Step 5: check, then Create customer](/docs-images/guide/step5-review.webp) ## Saved together, or not at all **Create customer** writes the group, companies, contracts, sites and headcount in a single transaction. If anything fails — a name already taken, a contract number in use — **nothing** is created, the page says what went wrong, and your entries stay as they are so you can fix them and try again. If the connection drops while saving, the wizard retries by itself. Each setup carries its own reference, so a retry, a double click or a second tab can never create the customer twice: the second attempt gets back the first result. Your entries are kept in this browser while you work, so a reload or a closed tab does not lose them. **Start over** clears them. ![Customer set up](/docs-images/guide/done.webp) The new sites appear under **Clients & Sites**, and the [daily report](/docs/daily-report) shows their approved headcount straight away: ![The new site in Client sites](/docs-images/guide/list-sites.webp) ![The daily report with the new site's approved headcount](/docs-images/guide/daily-report-approved.webp) ## Rules the wizard enforces - A company name that already exists in the workspace can't be created again — add the existing one instead. Group names are unique too. - A company already in one customer group can't be added to a different new group. - GSTIN must be a valid 15-character GSTIN. Contact email and phone must be valid if given. - A contract can't end before it starts. Contract numbers are unique in the workspace. - A site must belong to the same company as its contract. - Latitude and longitude come together, within range. Geofence radius is whole metres, 10 to 20,000. - A designation appears once per site; the approved number is a whole number from 0 to 10,000. - At most 50 companies, 100 contracts and 200 sites per setup. The server checks every one of these again, whatever the browser sends. ## After setup - Give the customer a login scoped to their company ([Administration](/docs/administration#limit-what-someone-can-see-data-scopes)). A customer login sees its own group and its own contracts, never anyone else's. - Check each site's gate location before guards start checking in. - Everything can be edited later in [Clients and sites](/docs/clients-and-sites). ## How it connects - The approved headcount is the **Total approved** column of the [daily report](/docs/daily-report). - [Deployments](/docs/deployment), [attendance](/docs/field-attendance) and [billing](/docs/payroll-and-billing) work per client and site exactly as before; groups and contracts add the levels above them. --- # Administration > Give people logins and roles, link logins to employee records, limit what each login sees with data scopes, set code numbering, and read the audit log. Sidebar → **Administration** (route `/administration`). It is for admins: anyone with `tenant.manage` or `audit.read`. The page has these sections, top to bottom: 1. Summary: workspace, members, role grants and data scopes counts. 2. **Employee Code Settings** and **Organization and Client Code Settings**: numbering. 3. **Employee Directory**: a searchable list of employees. 4. **Reporting Manager**: who can be picked as a reporting manager. 5. **Email Invitations**: invite by email link. 6. **Workspace Members**: add people and change roles. 7. **Data Scopes**: limit what someone sees. 8. **Role Permissions**: what each role can do (read-only). 9. **Recent Audit Activity**: who changed what. ## Add a member (give someone a login) This is the usual way to give guards, supervisors, office staff and customers access. No email is sent; you hand over the details yourself. ![Administration: (1) the menu item, (2) Add member](/docs-images/guide/administration-members.webp) 1. **Workspace Members** → **Add member**. 2. **Sign in with**: choose **Email** or **Mobile number**. - **Email**: for anyone who is an employee, use **exactly the email on their employee record**. - **Mobile number**: for guards without an email. Use **the same mobile number as on their employee record**. On the sign-in page they type that number in **Email or mobile number**, plus the password. Choosing the role **Field Employee** switches to Mobile number when no email has been typed. 3. **Full name** (optional) and **Role**: Viewer, Field Employee, Supervisor, HR Manager, Ops Manager, Client, IT Admin or Admin. 4. **Sign-in password**: type one or press **Generate**. If the person already has a SecureForce login (for example from another workspace), tick or untick **Use this password even if they already have a SecureForce login** depending on whether you want to replace their password. 5. Press **Add member**. ![Add member with a mobile number: (1) Mobile number, (2) the number, (3) name, (4) role, (5) Generate, (6) Add member](/docs-images/guide/add-member.webp) The result lists what happened: - _Email confirmed and access is active_. - **Linked to their employee record**: the login is now connected to the employee with the same email (or, for a mobile login, the same mobile number). **Field employees and supervisors need this** to mark attendance. If it doesn't appear, the email or mobile number doesn't match exactly one employee: fix it on the employee record and add the member again. Press **Copy sign-in details** and share them privately (WhatsApp or in person), then **Done**. **Add another** clears the form. ![The new member's sign-in details, ready to copy](/docs-images/guide/member-added.webp) Adding a member again with the same email or mobile number is safe. It re-applies the role and re-links the employee record. ### Mobile-number logins **One account, two ways in.** Someone added by **Email** can also sign in with the mobile number on their employee record, using the same password. There is still only one account and one password. Someone added by **Mobile number** (no email) signs in with the number only. A guard with a mobile login has no email, so **Forgot password?** can't help them. If they forget it, use **Reset password** in the members table and give them the new one. Everywhere in SecureForce their login shows as their mobile number. ## Invite by email instead **Email Invitations**: enter an **Email** and **Role**, press **Invite**. The invitation appears in the list with its status and expiry. Use the copy action to get the secure link and send it yourself. The person signs in through the link and the role becomes active. ## Change a role, suspend, reset a password In **Workspace Members**, each row has a **Role** and **Status** (active, invited, suspended) dropdown. Change them and press **Save** on that row. **Reset password** sets a new password for the member. ## Limit what someone can see (data scopes) **Data Scopes → Assign scope**: 1. **Member**: the login to limit. 2. **Scope type**: all, branch, client, site or employee. 3. **Scope target**: the specific branch, client, site or employee. 4. Press **Assign**. Typical setup: | Who | Scope | | ---------------------------- | ---------------------------------------------------------------- | | Site supervisor | site → their site (add one scope per site if they cover several) | | Customer login (role Client) | client → their organisation | | Branch manager | branch → their branch | Scopes are listed on the right; remove one to widen that person's view again. **A role with no scope sees the whole workspace.** ## Numbering **Employee Code Settings**: **Prefix** (EMP), **Start number** and **Padding** (number of digits), with a live **Preview** (EMP-0001). Press **Save**. The same controls exist for vendor company, branch, department, service line, grade, client and site codes. New records use the new format; existing codes don't change. ## GST and statutory settings The **GST and Statutory Settings** card configures tenant defaults for client billing and payroll: - **GST Configuration**: enable GST, choose the default treatment, and set CGST, SGST and IGST percentages. Intra-state needs CGST and SGST above zero; inter-state needs IGST. - **Statutory Settings**: effective date and PF, ESI and Professional Tax rates, ceilings and PT slabs. Disabled schemes are skipped by payroll. - **Configuration Status**: validates percentages and PT JSON before saving. Invalid settings block the update; unsaved changes can be discarded. Supplier legal name, GSTIN, state code and invoice numbering live in **Billing Profile**. Client GST identity is maintained in [Clients and sites](/docs/clients-and-sites). ## Reporting managers Tick which active employees may be chosen as a **Reporting Manager**. Only ticked people appear in the reporting-manager dropdown during onboarding. ## Audit log **Recent Audit Activity** lists inserts, updates and deletes with the record, the actor and the time. Filter by action, entity and number of rows, press **Apply filters**, open **Details** to see exactly what changed, and **Export** for an auditor. --- # Employees > Add employees one by one or in bulk from a CSV, set up the document types you collect, and use the employee profile that ties every module together. Sidebar → **Employees** (route `/employees`). Every person you manage has **one employee record**, whether guard, supervisor or office staff. Onboarding, KYC, deployment, attendance, leave and payroll all hang off this record. **Who can do this:** Admin, Ops Manager, HR Manager (permission `employees.manage`). ## Add an employee ![Employees: (1) Add employee for one person, (2) Bulk Onboarding for many](/docs-images/guide/employees.webp) **Employee Directory → Add employee**: | Field | Required | Notes | |---|---|---| | First name | Yes | | | Last name | | | | Phone | Yes | Mobile number, 10 to 15 digits. Spaces and dashes are removed. | | Email | | Optional, since many guards have none. If the person will sign in with an email, enter it here: it links their login to this record. Must be unique in the workspace. | | Emergency Contact Name | | | | Relationship | | Spouse, Parent, Sibling or Friend | | Emergency Contact Number | Yes | 10 to 15 digits | | Company, Branch, Department, Grade | | From [Organization](/docs/organization) | | Reporting Manager | | Only people ticked as reporting managers in Administration | | Hire Date | | | ![Add employee: (1–2) name, (3) mobile number, (4–5) emergency contact and number, (6) branch, (7) Save](/docs-images/guide/add-employee.webp) The **employee code** (EMP-0001…) is generated. New employees start with status **Pending onboarding** (added, but onboarding not started yet), then move to **Onboarding** and **Active**. Hover a status in the directory to see what it means. ## Document types Lower on the same page: **Document Types → Add document type**. This is the list of documents you collect from staff. ![Document Types, with Add document type](/docs-images/guide/document-types.webp) | Field | Notes | |---|---| | Code | Short and unique, e.g. AADHAAR, PAN, POLICE_VERIFICATION | | Name | e.g. *Aadhaar card*, *Police verification certificate* | | Requires Expiry | **Yes** for documents that lapse (police verification, licences) | | Required for Onboarding | **Yes** means **every worker** must submit it before onboarding can be completed | Documents that only some workers need — a PSARA certificate for guards, an ITI certificate for electricians — are not marked required here. Add them as rules per staff category or designation in [Document rules](/docs/document-rules). Starting a [KYC case](/docs/kyc) adds the ten standard document types automatically (Aadhaar, PAN, photograph, address proof, previous employment certificates, police verification, medical certificate, PSARA training, bank proof, education certificate) if they aren't there yet. ## The employee profile Each row in the directory has a **Profile** button (route `/employees/`). The profile is where every module meets: - Header: name, code, email, phone, status, company, branch, department and grade. - **Onboarding** banner: **Start onboarding**, or the current progress. - **Employment**: reporting manager, laptop ID, hire date, termination. - **Documents**, **Deployments**, **Roster Assignments**, **Attendance**, **Checks** (consents and verifications), **Payroll**, **Billing** and **Compliance**: everything recorded for this person in the other modules. - **Activity Timeline**: every change to the record, from the audit log. ![An employee's profile](/docs-images/guide/employee-profile.webp) ## Import many people at once (bulk onboarding) **Employee Directory → Bulk Onboarding** (route `/employees/bulk-onboarding`) is for batch hiring, or for moving staff over from another system. ![Bulk Onboarding: (1) Get the template, then drop the filled file on the box](/docs-images/guide/bulk-onboarding.webp) 1. Press **Get the template** to download the CSV with the right columns. 2. Fill one row per person. Columns: | Column | Required | Notes | |---|---|---| | first_name | Yes | | | last_name | | | | phone | | | | email | | Unique; also used to link a login later | | laptop_id | | For office staff with a company laptop | | reporting_manager | | The manager's employee code, email or full name | | company_name, branch_name, department_name, grade_name | | Must match names in Organization | | hire_date, date_of_birth | | YYYY-MM-DD | | address, emergency_contact | | | | bank_account_holder, bank_name, account_number, bank_ifsc, bank_branch | | If any bank field is given, all must be | | client_name, site_name | | Give both or neither; the site must belong to the client | | service_line_name, role_title | | e.g. *Manned guarding*, *Security Guard* | | pay_rate, bill_rate | | Per day; not negative | 3. Upload it. Every row is checked **before anything is saved**. The preview shows what will be imported and the assignment (client · site · role) for each person. 4. Press **Import & onboard**. Employees are created; rows with problems are listed under **Not imported** with the reason, so you can fix just those and upload them again. 5. In **Documents & deployment**, pick each imported person, upload and verify their documents, then press **Deploy employee**, or **Deploy all verified** for everyone ready. If the CSV named a client, site and rates, that deployment is created. **Import CSV** on the directory is a simpler import of employee details only. ## How it connects - [Administration → Add member](/docs/administration#add-a-member-give-someone-a-login) links a login to the employee with the same email, or with the same mobile number for a mobile login. - [Onboarding](/docs/onboarding) and [KYC](/docs/kyc) work on this record. - [Deployment](/docs/deployment), [roster](/docs/shifts-and-roster), [attendance](/docs/field-attendance), [leave](/docs/leave) and [payroll](/docs/payroll-and-billing) all point at it. --- # Document rules > Decide which documents are mandatory for each staff category and designation, and how HR approval is refused until every one is in. Sidebar → **Document Rules** (route `/document-rules`). Every worker owes a set of documents before HR can approve them. That set is built from three layers: | Layer | Set where | Example | |---|---|---| | **Every worker** | Employees → Document Types → **Required for Onboarding: Yes** | Aadhaar, PAN, bank proof, photograph | | **Their category** | Document Rules → a rule for the category | Security Guards: PSARA training certificate, police verification | | **Their designation** | Document Rules → a rule for one designation | Electrician: ITI certificate or electrical licence | A worker owes the union of all three: the common set, plus whatever their category adds, plus whatever their designation adds. **Who can do this:** HR Manager and Admin (`documents.manage`) for rules; HR, Ops Manager and Admin for categories and designations. ## Set up categories and designations ![Document Rules: (1) the menu item, (2) Add the standard categories](/docs-images/guide/rules-empty.webp) ![The standard staff categories](/docs-images/guide/categories.webp) On a new workspace, **Add the standard categories** in the *Who must submit what* panel adds the journey's list: Security Guards, Housekeeping, Operators & Technicians, Landscape, House Management, Finance, HR and Admin, with the designations Security Guard, Electrician, Plumber, Lift Operator, STP Operator, WTP Operator and Gardener. Pressing it again adds nothing twice. Rename, add or archive any of them in the **Staff categories** and **Designations** lists below. - A **designation** belongs to one category. Use the same spelling as in the approved headcount and deployments (e.g. *Security Guard*), because the daily report matches designations by name. - To retire a category or designation, set **Status → Archived**. One that workers or rules still use can't be deleted. - A designation already used by workers or rules can't move to another category; create a new one instead. ## Add a rule **Mandatory document rules → Add rule**: | Field | Notes | |---|---| | Document | Any active [document type](/docs/employees#document-types) | | Category | The category the rule applies to | | Only for designation | Optional. Leave empty for every worker in the category; pick one to apply it to that designation only | | Rule | **Active**, or **Switched off** to stop applying it without deleting it | ![A rule for a category: (1) the document, (2) the category, (3) Save](/docs-images/guide/add-rule-category.webp) ![A rule for one designation: (1) the designation](/docs-images/guide/add-rule-designation.webp) ## Who must submit what The panel at the top shows the resulting list for *Every worker*, each category, and each designation that has its own rules, colour-coded by where each document comes from. It is the table to send to the client to confirm, line by line. ![Who must submit what](/docs-images/guide/who-must-submit-what.webp) ## What it changes for HR approval **Onboarding can't be completed — HR can't approve — while anything is outstanding.** This is checked by the server, not just the screen, so it holds however the case is updated. The refusal names exactly what is missing, e.g. *"Onboarding cannot be approved yet. Still outstanding: PAN card, ITI certificate."* A mandatory document counts once it is **Verified** and not past its expiry date. A verified document whose expiry date has passed counts as **Expired** again. Once a workspace has at least one active category, **every worker needs a category** before approval, so category rules can't be skipped by leaving it blank. If the worker's category has designation-specific rules, they need a **designation** too. Approval already given is never undone by a later rule change; the new rule applies the next time a case is approved. ## Where people see it On the employee's [onboarding](/docs/onboarding#2-document-upload) **Document Upload** step: - **Staff category and designation** at the top, which decide the list. - **Required** lists this worker's mandatory documents, each with where it comes from (*Every worker*, *Security Guards*, *Electrician*) and its state: **Not uploaded**, **Awaiting verification**, **Verified**, **Rejected**, **Expired** or **Waived**. - A line underneath says either that nothing blocks approval, or exactly what still does. ![The required list, with what still blocks approval](/docs-images/guide/required-list.webp) ## Waive a document for one worker Sometimes a mandatory document genuinely doesn't apply — a first-time worker has no previous employer certificate. On the Document Upload step, HR presses **Waive** next to it and gives a reason (at least 5 characters). The document then counts as satisfied for that one worker. The reason, who waived it and when are kept in the audit log. **Remove waiver** makes it mandatory again. Only HR (`documents.manage`) can waive. Ops Managers see the status but can't waive. ![Waive a document for this worker](/docs-images/guide/waive-button.webp) ![Waive: (1) the reason, (2) Waive document](/docs-images/guide/waive-dialog.webp) ![Every mandatory document in](/docs-images/guide/all-in.webp) ## Before any rules exist A workspace with no categories and no rules behaves exactly as before: the documents marked **Required for Onboarding** are the whole list. ## How it connects - [Onboarding](/docs/onboarding) step 2 and step 3 use this list. - The list of documents comes from [Employees → Document Types](/docs/employees#document-types). - [KYC](/docs/kyc) keeps its own checklist; this rule is about HR approval. --- # Onboarding > The six-step onboarding checklist for each new employee, ending with their deployment to a client site, and the Onboarding tracker. Every new person goes through a six-step checklist that ends with them posted at a site. Start it from the employee's profile; track everyone on the **Onboarding** page. **Who can do this:** Admin, HR Manager (`onboarding.manage`), with `documents.manage`, `consents.manage` and `verifications.manage` for steps 2–5. ## Start Sidebar → **Employees** → **Profile** on the person's row → **Start onboarding**. This opens the wizard at `/employees//onboarding`. The left column lists the six steps with their state (**Complete**, **In progress**, **Locked**). The top shows **Onboarding progress** (e.g. 1 of 6 sections complete). **Each step unlocks when the one before it is complete.** **Save** keeps your work; **Save & Continue** moves on. **Previous** and **Next** move between steps. ## 1. Profile Information Check the name, phone and (optional) email, and fill in the required **Date of birth**, **Hire date**, **Address** and **Emergency Contact Number**. Optional: the emergency contact's **name** and **relationship**, **Reporting Manager**, **Laptop ID**. **Save** keeps a half-filled profile; **Continue** needs the phone and emergency contact number. ![Onboarding: (1) the six steps, done in order, (2) Save & Continue](/docs-images/guide/onboarding-profile.webp) ## 2. Document Upload At the top, choose the worker's **Staff category** and **Designation** (e.g. *Operators & Technicians · Electrician*) and press **Save**. They decide which documents are mandatory for this worker — see [Document rules](/docs/document-rules). Once your workspace uses categories, a worker without one can't be approved. ![Document Upload: (1) category, (2) designation, (3) Save](/docs-images/guide/choose-category.webp) **Required** then lists this worker's mandatory documents: the ones every worker needs, plus what their category and designation add. Each line says where it comes from and its state (**Not uploaded**, **Awaiting verification**, **Verified**, **Rejected**, **Expired**, **Waived**). Everything else is under **Optional**. Press **Upload** next to each and choose the file (PDF, JPG, PNG or WEBP). On a phone this can open the camera. Each upload shows as **Submitted**; **Re-upload** replaces it. If a mandatory document genuinely doesn't apply to this person (e.g. a first-time worker has no previous employer certificate), HR can press **Waive** and give a reason. The reason and who gave it are recorded. A line under the list says either that nothing blocks approval, or exactly which documents still do. ![The required documents, with what is still missing](/docs-images/guide/required-list.webp) If it says "No document types configured", add them first under Employees → Document Types. ## 3. Document Verification Each upload is listed with **View**, **Verify** and **Reject**. Open it, check it against the original, and press **Verify**, or **Reject** if it's wrong or unreadable (the person then re-uploads in step 2). Every required document must be **Verified** (and, if it has an expiry date, not expired) or waived to continue. ![Document Verification](/docs-images/guide/onboarding-verification.webp) ## 4. Bank Details **Account holder**, **Bank name**, **Account number**, **IFSC**, **Branch**. Payroll uses this account; the holder's name should match the Aadhaar. ![Bank Details: (1) this step, (2) the account holder as on Aadhaar, (3) Save & Continue](/docs-images/guide/onboarding-bank.webp) ## 5. Compliance & Consents - **Required consents**: press **Request**, then **Mark Granted** once the person has agreed (**Withdraw** undoes it). - **Required verifications** (background checks): press **Initiate** when you send the check off, then **Mark Clear** when it comes back clean, or **Mark Failed**. A failed check can be retried with **Retry**. The step is complete when every consent is **granted** and every verification is **clear**. ![Compliance & Consents: Request each consent, Initiate each check](/docs-images/guide/onboarding-consents.webp) ## 6. Deployment Press **Add deployment** and choose: | Field | Required | Notes | |---|---|---| | Client | Yes | | | Site | Yes | Only that client's sites are listed | | Service line | | | | Role title | | e.g. *Security Guard*. **Spell it exactly as the approved headcount designation.** | | Pay rate | | Per day: what you pay the person | | Bill rate | | Per day: what you charge the client | For new hires, [Approve & Deploy](/docs/approve-and-deploy) does this step for you. Here it already shows the deployment it created: ![Deployment: the worker's deployment](/docs-images/guide/onboarding-deployment.webp) Press **Create deployment**. The deployment starts today. Change its start date, status or end date later on the [Deployment](/docs/deployment) page. When all six steps are done, the banner shows **Onboarding complete**. ## HR approval and mandatory documents Completing onboarding is HR's approval of the worker. **It is refused while any mandatory document is outstanding** — missing, awaiting verification, rejected, or past its expiry date and not waived — or while the worker has no staff category (once your workspace uses categories). This is enforced by the server, so it also applies to bulk onboarding and to editing a case's status directly; the message names exactly what is missing. An approval already given is never undone by a later rule change. For new hires, the formal sign-off — salary structure, e-signed contract, optional second approver, employee ID — is on **[HR approval](/docs/hr-approval)**, followed by **[Approve & Deploy](/docs/approve-and-deploy)**, which creates the deployment that completes step 6. ## The Onboarding tracker Sidebar → **Onboarding** (route `/onboarding`) lists everyone being onboarded with their progress, documents, deployment records and blockers. Counts at the top show **Total onboarding cases**, **Deployment ready**, **Needs attention** and **In progress**. Filter by **Deployment ready**, **Needs attention**, **Draft**, **In progress**, **Blocked**, **Completed** and **Cancelled**. ![The Onboarding tracker, with its filters](/docs-images/guide/onboarding-tracker.webp) ## How it connects - Uses the [employee](/docs/employees) record and the document types. - Step 6 creates the [deployment](/docs/deployment) that the [roster](/docs/shifts-and-roster), [daily report](/docs/daily-report), [payroll and billing](/docs/payroll-and-billing) rely on. - For security staff, also run [KYC](/docs/kyc) before deploying. --- # HR approval > Approve a new worker on a pre-approved salary structure with an e-signed employment contract, optionally with a second HR approver (maker-checker), and issue the employee ID and ID card. Sidebar → **HR Approval & Deploy** (route `/hr-approval`). Onboarding is complete when HR signs off. That sign-off has four parts: 1. **Checks** — the profile, the [mandatory documents](/docs/document-rules) and [KYC](/docs/kyc) are in. 2. **Salary** — HR picks a structure from the pre-approved **salary table**. 3. **Contract** — SecureForce writes the employment contract from the salary, and the worker **e-signs** it. 4. **Approval** — HR approves; the **employee ID** is issued and the **ID card** can be printed. After approval, the worker is [allocated and deployed](/docs/approve-and-deploy). **Who can do this:** HR Manager and Admin (`onboarding.manage`). The salary table is maintained by `payroll.manage` holders (HR Manager, Admin). Operations Managers can see whether a worker is approved — to deploy them — but never the salary breakdown. ## The salary table Sidebar → **Salary Structures** (route `/salary-structures`) → **Add salary structure**: | Field | Notes | |---|---| | Name, Code | e.g. *Security Guard — Bengaluru 2026*, *SG-BLR-26* | | Only for category / designation | Optional. When set, the structure can only be used for those workers | | Basic, HRA, Conveyance, Special allowance, Other allowances | Monthly amounts. Basic must be above zero | | Working days per month | 20–31, default 26 | | PF applicable, ESI applicable | Printed in the contract | | Effective from | The structure can't be used for a salary starting earlier | | Status | **Active** structures appear at approval. Archive old ones; a structure workers were approved on can't be deleted | ![Add salary structure: (1) name, (2) category, (3) monthly amounts, (4) Save](/docs-images/guide/salary-structure-add.webp) SecureForce works out **Gross per month** and the **Daily rate** (gross ÷ working days). The daily rate is the deployment's pay rate, which [Payroll Prep](/docs/payroll-and-billing) multiplies by days worked. ![Salary Structures: (1) the menu item, (2) Add salary structure](/docs-images/guide/salary-structures.webp) A worker keeps the terms they were approved on: editing a structure later never changes an approved worker's salary. ## Settings (admins, once) At the top of HR Approval & Deploy, admins see **HR approval settings**: | Setting | Default | What it does | |---|---|---| | Maker-checker: a second HR user approves | Off | The person who prepares an approval can't approve it | | Contract must be signed before approval | On | Approval waits for the worker's signature | | Every worker needs a cleared KYC case | Off | When off, KYC is checked only for workers who have a case | | No deployment without HR approval, from any screen | Off | Also blocks the Deployment page, bulk onboarding and CSV imports for unapproved workers | | Days rostered on deploy | 31 | 7–62 days of roster created by [Approve & Deploy](/docs/approve-and-deploy) | ![HR approval settings: Maker-checker](/docs-images/guide/hr-settings.webp) ## Approve a worker ### 1. Open the worker The board groups everyone in onboarding: **Ready for HR approval**, **Awaiting approval**, **Approved — ready to deploy**, **Documents outstanding**, **Deployed**. Click **Open**. ![HR Approval & Deploy: (1) the menu item, (2) Ready for HR approval, (3) open the worker](/docs-images/guide/hr-board.webp) The worker's page shows five steps across the top — Checks, Salary & contract, Worker signs, HR approves, Approve & Deploy — turning green as each is done. ### 2. Checks **Checks before approval** lists Profile (mobile number, date of birth), Mandatory documents and KYC. A red line says what is missing, with a button to fix it. ### 3. Choose the salary and prepare Choose the **Salary structure** and the date the **Salary starts**, check the breakdown, and click **Prepare approval and contract**. ![Prepare: (1) every check green, (2) the salary structure, (3) Prepare approval and contract](/docs-images/guide/prepare.webp) **Change salary** prepares it again later; the unsigned contract is cancelled and a new one written. ### 4. The worker signs the contract Click **Sign with the worker** (route `/sign/`). The contract is written from the salary structure — name, employee ID, designation, each salary component, PF and ESI — and shows its **SHA-256 fingerprint**. Read it to the worker if needed and hand them the device. The worker types their **full name** (it must include their first name), **signs in the box** with a finger, ticks **I have read and agree**, and presses **Sign agreement**. ![Waiting for the worker's signature: Sign with the worker](/docs-images/guide/awaiting-signature.webp) ![The contract the worker reads](/docs-images/guide/contract-read.webp) ![Signing: (1) full name, (2) signature, (3) tick to agree, (4) Sign agreement](/docs-images/guide/contract-sign.webp) The typed name, drawn signature, time and device are recorded. A signed agreement can never be edited or deleted — only voided by HR with a reason. A worker with their own login can open the same link and sign themselves. ![Signed](/docs-images/guide/contract-signed.webp) ### 5. Approve Click **Approve** (and add a note if you like). With **maker-checker** on, the person who prepared it sees this instead, and a second HR user approves: ![Maker-checker: a second HR user approves](/docs-images/guide/maker-checker.webp) Once approved, the salary is fixed, the **employee ID is issued**, and the worker moves to **Approved — ready to deploy**. ![Approve](/docs-images/guide/approve-button.webp) ![Confirm the approval](/docs-images/guide/approve-dialog.webp) ![Approved](/docs-images/guide/approved.webp) **Reject** needs a reason; the unsigned contract is cancelled and HR can prepare again later. ## The employee ID and ID card The worker's **employee code** (e.g. PIFM0101) is their employee ID; approval issues it. **ID card** (top right of the worker's page, route `/employees//id-card`) shows a credit-card-size card with the face registered at deployment, designation, issue and validity dates (one year) and the emergency number. **Print ID card** prints just the card. ![The ID card](/docs-images/guide/id-card.webp) ## What the server checks Approval is refused — whatever screen it comes from — when a check is red, when the contract isn't signed (if required), or, with maker-checker on, when the approver prepared it themselves. The message says exactly why, e.g. *"Not ready for approval. Mandatory documents: Outstanding: PAN card."* ## Good to know - The e-signature is an electronic record (typed name, drawn signature, time, device, and the fingerprint of the exact text). An Aadhaar-based eSign would need an eSign provider to be connected. - You can change the contract and NDA wording for your workspace; until you do, SecureForce's standard wording is used. ## How it connects - Needs the [mandatory documents](/docs/document-rules) and, where there is one, a cleared [KYC](/docs/kyc) case. - Followed by [Approve & Deploy](/docs/approve-and-deploy). - The approved daily rate flows into [payroll](/docs/payroll-and-billing). --- # KYC verification > Run the ten pre-hire checks for a security guard (identity, address, employment history, police, medical, PSARA training, references, bank), fetch documents from DigiLocker, and clear the candidate for deployment. Sidebar → **KYC Verification** (route `/kyc`). For security staff, the PSARA rules expect identity, address, police verification, medical fitness, training and previous-employment checks before someone is posted at a client. Each candidate gets a **KYC case** with ten standard checks. A case is **cleared** only when every mandatory check is signed off. **Who can do this:** Admin, HR Manager (`kyc.manage`); Ops Manager can view. ## Open a case 1. **Start a KYC case**. ![KYC Verification: (1) the menu item, (2) Start a KYC case](/docs-images/guide/kyc-queue.webp) 2. Choose the candidate (any employee who doesn't have a case yet). If the list is empty, add the employee first. 3. **Open case**. The case is created with the ten checks, plus any missing standard document types. ![Start a KYC case: (1) the candidate, (2) Open case](/docs-images/guide/kyc-start.webp) 4. It appears in the list as **Draft** with, e.g., "0 of 7 mandatory checks verified". Click the card to open it (route `/kyc/`). ![The new case: click the card](/docs-images/guide/kyc-card.webp) ## The case page - **Header**: mandatory checks verified so far, failed checks, previous employers confirmed. - **Decision bar**: the status and what is still outstanding, with **Start review**, **Hold**, **Reject** and **Clear for deployment**. - **Verification checklist**: the checks, grouped by kind. - **Previous employment**: employers to confirm. - **Candidate**: code, phone, email, date of birth, employment status, date opened. - **DigiLocker**: fetch documents from the issuer. - **Documents**: everything filed for the candidate, with **View** and **Upload**. ![The case page: the header, the decision bar and the checklist](/docs-images/guide/kyc-case.webp) ## The ten checks | Check | Kind | Mandatory | Document | |---|---|---|---| | Aadhaar card | Identity | Yes | AADHAAR. Enter the 12-digit number; it is checksum-validated and shown masked. | | PAN card | Identity | Yes | PAN. Enter the 10-character PAN (format AAAAA9999A). | | Passport size photograph | Identity | Yes | PHOTO | | Permanent address proof | Address | Yes | ADDRESS_PROOF | | Previous employment certificates | Employment | Yes | PREV_EMP_CERT | | Police verification certificate | Police | Yes | POLICE_VERIFICATION | | Medical fitness certificate | Medical | Yes | MEDICAL_CERT | | PSARA security training certificate | Education | | PSARA_TRAINING | | Reference check | Reference | | none | | Bank account proof | Bank | | BANK_PROOF | The exact mandatory set is shown on the case ("N of 7 mandatory checks") and marked **Required** on each check. ## Sign off a check 1. Click the check to open it. It shows guidance on what to look for. 2. Upload or link the document, or fetch it from DigiLocker. 3. For Aadhaar and PAN, type the number in the field. **The check can't be set to Verified until a valid number is entered** ("Not captured yet"). 4. Add **Notes**: who you spoke to and what you saw. 5. Set the result: **Not started**, **In progress**, **Verified**, **Failed** or **Waived** (not applicable). ![Signing off a check: (1) open it, (2) Verified](/docs-images/guide/kyc-check.webp) ## Previous employment **Add employer** → **Company**, **Designation**, **Contact**, **From**, **To**, **Contact phone**, **Reason for leaving** → **Add employer**. After phoning the employer, press **Confirmed** (or **Could not confirm**). **Remove** deletes the entry. ![Add a previous employer: (1) company, (2) phone number for the reference, (3) Add employer](/docs-images/guide/kyc-previous-employer.webp) ## DigiLocker The **DigiLocker** panel shows which mandatory checks can be pulled from DigiLocker (e.g. Aadhaar from UIDAI, PAN from the Income Tax Department). Press **Request from DigiLocker**: the candidate signs in to DigiLocker in the window that opens and approves with their own OTP; SecureForce never sees their password or OTP. Fetched documents are marked as coming from DigiLocker. The DigiLocker connection must be configured for your account. ![The DigiLocker panel: Request from DigiLocker](/docs-images/guide/kyc-digilocker.webp) ## Decide - **Start review**: mark the case as in review. - **Hold**: pause it (e.g. waiting for a police certificate). - **Reject**: the candidate fails KYC. - **Clear for deployment**: enabled only when every mandatory check is **Verified** or **Waived** and nothing has **Failed**; otherwise hover it to see why. In the dialog, set **Re-verification due** (police verification lapses; the case is flagged again from a month before) and **Notes** for the client's audit, then press **Clear candidate**. ![Every check verified: (1) Clear for deployment, (2) or Reject](/docs-images/guide/kyc-all-verified.webp) ![Clear this candidate: (1) re-verification date, (2) Clear candidate](/docs-images/guide/kyc-clear.webp) ![The cleared case](/docs-images/guide/kyc-cleared.webp) The KYC page header counts **Awaiting review**, **Cleared** (deployable) and **Needs re-verification**. Filter cases by status or search by name, code or phone. ## How it connects - Works on the [employee](/docs/employees) record and their documents (shared with [onboarding](/docs/onboarding)). - A cleared case records a verification against the employee; re-verification dates feed [compliance](/docs/compliance) follow-up. --- # Approve & Deploy > Allocate an HR-approved worker to a customer site — designation, shift and weekly off or reliever, client NDA, face — and send them to attendance, payroll, billing and the customer's report in one click. On an HR-approved worker's page (Sidebar → **HR Approval & Deploy** → the worker), the **Allocate and Approve & Deploy** card places the worker at a post. One click then hands them to every system that needs them: | System | What happens | |---|---| | **Attendance** | Rostered on the shift for the coming days (31 by default, set in [HR approval settings](/docs/hr-approval#settings-admins-once)), skipping the weekly off; their **face is registered** for supervisors to compare with check-in photos | | **Payroll** | The deployment's pay rate is the approved salary's **daily rate** | | **Billing** | The deployment's **bill rate** to the customer | | **Customer** | Counted as **Deployed** in the customer's [daily report](/docs/daily-report) | | **Contract records** | The signed contract and, where needed, the signed **client NDA** are kept with the worker | It is all-or-nothing, and a double click or retry never deploys the worker twice. **Who can do this:** Operations Manager, HR Manager, Admin (`deployments.manage`). The worker must be [HR-approved](/docs/hr-approval) first. ## 1. Where Choose the site; the list reads **customer group › company › site**. The site's contract is shown below it. If the contract needs a **client NDA**, press **Prepare NDA and sign**; the worker signs it the same way as the contract. ![Where: (1) the site, (2) the client NDA is needed, Prepare NDA and sign](/docs-images/guide/deploy-nda.webp) ![The client NDA the worker reads](/docs-images/guide/nda-read.webp) ![The NDA signed](/docs-images/guide/nda-signed.webp) ## 2. Post, money and face | Field | Notes | |---|---| | Designation | e.g. *Security Guard*. Spell it as in the approved headcount; suggestions appear | | Starts on | Not before the approved salary starts; within 30 days back and 180 days ahead | | Shift | Shifts for this site, or for all sites | | Weekly off | The day the worker is not rostered | | Reliever / floater | No fixed shift. Their days are paid at the deployment's pay rate and billed at its bill rate, with or without a roster ([how](/docs/payroll-and-billing#how-amounts-are-worked-out)). A reliever can't have a shift | | Pay rate | Shown from the HR approval | | Bill rate to customer (per day) | Filled in from the last deployment of this designation at the site, if any | | Face for attendance | **Take face photo**: the worker faces the camera (or choose a photo file) | When everything is right the button says **Ready to deploy**; otherwise it lists exactly what to fix. ![The deploy form: (1) role, (2) shift, (3) weekly off or reliever, (4) face photo, (5) Approve & Deploy](/docs-images/guide/deploy-form.webp) ## 3. Approve & Deploy Press **Approve & Deploy**. The result shows each system the worker was sent to. ![Deployed to every system](/docs-images/guide/deployed.webp) ![The Deployed tab](/docs-images/guide/board-deployed.webp) ![The daily report counts the new worker](/docs-images/guide/daily-report-deployed.webp) ## Moving a worker to another site Choose the new site and tick **End the current deployment**. The current deployment ends the day before the new start, its future roster days are cancelled (days already worked are kept), and the new deployment starts — in the same click. ## The registered face in the muster In [Field Attendance](/docs/field-attendance) → **Muster**, opening a worker shows the **registered face** next to the day's check-in photo, so a supervisor can spot a colleague punching in for an absent guard. ![The muster: today's check-in next to the registered face](/docs-images/guide/muster-registered-face.webp) The comparison is by eye: SecureForce does not do automatic face recognition. ## What the server checks Deployment is refused when the worker isn't HR-approved, when a check has gone red since approval (for example a document expired), when the site's contract needs an NDA that isn't signed, when the site or contract is inactive, when the shift belongs to another site, or when the worker is already deployed and **End the current deployment** isn't ticked. The message says which. ## How it connects - Comes after [HR approval](/docs/hr-approval). - The deployment appears on the [Deployment](/docs/deployment) page like any other, and drives [shifts and roster](/docs/shifts-and-roster), [field attendance](/docs/field-attendance), [payroll and billing](/docs/payroll-and-billing) and the [daily report](/docs/daily-report). --- # Deployment > Post a person at a client site in a role, from a start date, with a pay rate and a bill rate. This drives the daily report's "Deployed" count, payroll and billing. Sidebar → **Deployment** (route `/deployment`). A **deployment** says who works where, as what, from when, and at what rate. It is the link between a person and a site. **Who can do this:** Admin, Ops Manager, HR Manager (`deployments.manage`); supervisors can view. ## Where deployments come from - **[Approve & Deploy](/docs/approve-and-deploy)** on an HR-approved worker: sets the pay rate from the approved salary, rosters the shift, registers the face, and handles the client NDA — the recommended way for new hires. - Onboarding step 6 ([Onboarding](/docs/onboarding#6-deployment)). - Bulk onboarding, **Deploy employee** / **Deploy all verified** ([Employees](/docs/employees#import-many-people-at-once-bulk-onboarding)). - This page: **Add deployment**, e.g. to move someone to another site. If an admin switches on **No deployment without HR approval** ([HR approval settings](/docs/hr-approval#settings-admins-once)), every route above refuses a worker HR has not approved. ## Add or edit a deployment ![Deployment: Add deployment, or Edit on a row](/docs-images/guide/deployment-list.webp) | Field | Required | Notes | |---|---|---| | Employee | Yes | | | Company, Branch | | Defaults from the employee in onboarding | | Client | Yes | | | Site | Yes | | | Service Line | | | | Role Title | | e.g. *Security Guard*. **Must match the designation in the approved headcount** for the daily report to count it. | | Start Date | Yes | The person counts as deployed from this date. Defaults to the day it's created. | | End Date | | Set it when the posting ends. | | Status | | **planned**, **active**, **completed**, **cancelled**. Planned and active both count as deployed between the start and end dates. | | Pay Rate | | Per day, paid to the person. Payroll uses it. | | Bill Rate | | Per day, charged to the client. Billing uses it. | ![Add deployment: (1) role title, spelled as in the approved headcount, (2) pay rate, (3) bill rate, (4) Save](/docs-images/guide/deployment-add.webp) ## Common tasks - **Move someone to another site:** set an **End Date** on the old deployment (status **completed**), then add a new one at the new site. - **Change a rate:** edit the deployment. Payroll and billing pick up the new rate the next time you press Generate. - **A person shows as "Cover from another post" on the daily report:** they were present at a site where they have no deployment, or their deployment's role title differs from the approved designation. ## How it connects - [Roster assignments](/docs/shifts-and-roster) should name the deployment. That link is what gives each day of attendance a pay rate and a bill rate. - The [daily report](/docs/daily-report) counts **Deployed** per site and designation. - [Payroll Prep](/docs/payroll-and-billing) uses the **pay rate**; [Billing Prep](/docs/payroll-and-billing) uses the **bill rate**. --- # Shifts and roster > Define shifts, roster each person on a shift at a site for each day, and manage attendance records by hand on the Attendance page. Sidebar → **Attendance** (route `/attendance`) has three lists: - **Shifts**: the time slots, e.g. Day 07:00–19:00, Night 19:00–07:00, General 09:00–18:00. - **Roster Assignments**: one person, one shift, one site, one date. - **Attendance Records**: what actually happened each day. Most are created by guards checking in on [Field Attendance](/docs/field-attendance); you can also add or fix them here. **Who can do this:** Admin, Ops Manager, Supervisor (`rosters.manage`, `attendance.manage`). ## Add a shift ![Attendance: the Shifts list, with Add shift](/docs-images/guide/shifts-list.webp) **Shifts → Add shift**: | Field | Required | Notes | |---|---|---| | Site | | Leave empty for a shift used at every site, or pick one site | | Shift Name | Yes | e.g. *Day* | | Starts At | Yes | 24-hour, e.g. 07:00 | | Ends At | Yes | e.g. 19:00 | | Crosses Midnight | | **Yes** for night shifts (19:00 → 07:00) | | Break Minutes | | e.g. 30. Subtracted from worked time. | | Status | | **draft**, **published**, **locked**, **cancelled**. Use **published**. | ![Add shift: (1) name, (2) start and end, (3) Save](/docs-images/guide/shift-add.webp) A check-in is **late** when it's more than the late-after grace (15 minutes by default) past the shift start. Set the grace in [Field Attendance → Setup](/docs/field-attendance#attendance-rules). ## Roster someone **Roster Assignments → Add roster assignment**: | Field | Required | Notes | |---|---|---| | Employee | Yes | | | Deployment | | **Pick the person's deployment.** This link gives the day a pay rate and a bill rate. Without it, payroll counts the day at ₹0 and flags it. | | Shift | Yes | | | Site | Yes | Where they work that day | | Roster Date | Yes | One row per day | | Status | | Use **published** | | Notes | | | ![Add roster assignment: (1) the deployment, which gives the rates, (2) one row per day, (3) Save](/docs-images/guide/roster-add.webp) > Workers placed with [Approve & Deploy](/docs/approve-and-deploy) are rostered automatically for the next days (31 by default), linked to their deployment. **A guard with no roster entry for today sees "No shift rostered" and can't check in.** The phone takes the site (for the location check) and the shift (for on-time or late) from today's roster. The **Deployment** dropdown shows each deployment as "role · start date" without the person's name. If several people share a role and start date, open the [Deployment](/docs/deployment) page to tell them apart. ## Attendance records by hand **Attendance Records → Add attendance record** creates a day manually, for staff who don't use the app or for corrections. Prefer the [muster](/docs/field-attendance#muster) for day-to-day marking and corrections: it keeps an audit trail and the original punches. ## How it connects - Uses [shifts](#add-a-shift), [deployments](/docs/deployment) and [sites](/docs/clients-and-sites). - [Field Attendance](/docs/field-attendance) reads today's roster for each guard and lists everyone rostered in the muster. - [Payroll and billing](/docs/payroll-and-billing) follow attendance → roster → deployment to find rates. --- # Field Attendance > Guards check in and out on their phone with a photo and a location check against the site boundary; supervisors check in guards without a smartphone by mobile number, run the muster, correct and approve days; Today and Performance show the numbers. Sidebar → **Field Attendance** (route `/field-attendance`). Guards check in at their post with a photo and their location. Supervisors run the muster and fix missed punches. The numbers flow straight into the [daily report](/docs/daily-report), [payroll and billing](/docs/payroll-and-billing). The page has up to five tabs, depending on your role: | Tab | Who sees it | What it's for | |---|---|---| | **My shift** | Anyone linked to an employee record | Your own check-in and check-out | | **Today** | Staff (not Field Employee or Client) | Every site at a glance | | **Muster** | Staff | Everyone rostered for a day; mark, correct, approve | | **Performance** | Staff | Attendance % and on-time % over a month | | **Setup** | Attendance managers, and anyone with `deployments.manage` (approved headcount) | Rules and approved headcount | ![Field Attendance: (1) the menu item, (2) Today, (3) Muster, (4) Performance, (5) Setup, which you do first](/docs-images/guide/field-attendance-tabs.webp) ## Before guards can check in All of these must be in place. [Quickstart](/docs/quickstart) covers them in order. 1. The site has a **latitude**, **longitude** and **radius** ([Clients and sites](/docs/clients-and-sites)). 2. The guard has an **employee record** with their email, and a **login** with role **Field Employee** that says **Linked to their employee record** ([Administration](/docs/administration)). 3. The guard has a **roster assignment for today** at that site ([Shifts and roster](/docs/shifts-and-roster)). 4. The phone allows **Camera** and **Location** for the SecureForce site, which needs HTTPS. ## Attendance rules **Setup → Attendance rules** apply to every site. Press **Save** after changing them. | Setting | Default | Meaning | |---|---|---| | Location check | Enforce | **Off**: location isn't checked. **Flag**: record the distance and flag off-site punches. **Enforce**: refuse a guard's own check-in from outside the boundary, or with a GPS fix too rough to place them there (worse than the boundary radius, minimum 100 m). Enforce never blocks a supervisor marking the muster, or a check-out, so a shift is never left unrecorded. A supervisor who checks someone in away from the site must type a reason, which is kept on the record. | | Late after (minutes) | 15 | Grace after the rostered start before a check-in counts as **late** | | Half day at or below (minutes) | 300 | Worked minutes (less the break) at or below which the day is a **half day** | | Default boundary (metres) | 200 | For sites without their own radius | | Early check-out grace (minutes) | 15 | Tolerance before an early finish is flagged | | Workspace time zone | Asia/Kolkata | Used for "today", shift times and lateness | | Photo at check-in and check-out | Off | Guards take a photo with the front camera at both punches. Dark or blurry photos are sent back for a retake. Stops a colleague punching for someone who isn't there. | | Photo of the site at check-in | On | Guards also photograph their post (gate, signboard or entrance) with the back camera when they check in. A check-in without it is refused. Not asked of a supervisor checking someone else in. | | Guards check in from their own phone | On | Turn off where the supervisor checks everyone in on one device ([Check in a guard](#checking-in-a-guard-who-has-no-smartphone)) | | A shift needs a check-out before approval | On | Open shifts stay out of approval until they are closed or corrected | ## Approved headcount **Setup → Approved headcount** holds the number of people the contract allows, per site and designation. The daily report's **Total approved** and **Shortage** come from it. 1. Pick the **Site**. It defaults to the first site in the list, so check it. 2. **Add designation**: type the designation **exactly as the deployments' Role Title** (e.g. *Security Guard*), or tap one of the suggestions. 3. Enter the **approved headcount** and press the save icon. The trash icon removes a row. The **Deployed** column next to it shows how many active deployments match. ![Setup: (1) location check, (2) late after, (3) photo at check-in, (4) Save rules; (5) the site and (6) its approved headcount per designation](/docs-images/guide/attendance-setup.webp) ## The guard's check-in (My shift) The guard signs in on their phone with their mobile number and password. ![Signing in on the phone: (1) mobile number, (2) password, (3) Sign in](/docs-images/guide/guard-sign-in.webp) After signing in, the guard lands on **My attendance**: - A greeting, the clock, today's status (**Not marked**, **Present**, **Late**…). - A large **Check in** button with a ring. - **Post** (the site) and **Shift** (name and times), from today's roster. - A location card: the distance from the site and its accuracy, with **Refresh location**. - **Today**: what has been recorded so far (check-in time with photo, check-out). To check in: 1. At the site, press **Refresh location** if needed. It should say *At — N m from the marked point*. If it says *outside the N m boundary* and the rule is **Enforce**, the button stays disabled. 2. Press **Check in**. ![Tap Check in](/docs-images/guide/guard-check-in.webp) 3. The camera opens with a face guide. Press **Take photo**. If the in-app camera doesn't work, **Use camera app** takes the photo with the phone's own camera. ![Take photo](/docs-images/guide/guard-selfie.webp) 4. If the photo passes the light and sharpness check, press **Use photo**. If not, **Take again**, or **Use anyway**, which marks it for the supervisor to check. ![Use photo](/docs-images/guide/guard-use-photo.webp) With **Photo of the site at check-in** on, the back camera opens next: fit the gate, signboard or entrance in the frame and press **Take photo**, then **Use photo**. Your location is checked again at this moment, so the check-in is placed where you are when you finish, not where you were when you started. 5. The button turns into **Check out**; **Today** shows the time, **On time** or **Late**, and the photos. ![Checked in: (1) Present, (2) inside the site, (3) the same button checks out](/docs-images/guide/guard-checked-in.webp) At the end of the shift, press **Check out** the same way. A night shift from yesterday that is still open shows a reminder to check out. ## Checking in a guard who has no smartphone Some guards have no smartphone, or one that can't run SecureForce. A **Supervisor**, **Operations Manager** or **Admin** checks them in and out from their own phone or laptop instead. The guard doesn't need a login, only an employee record with their mobile number. 1. **Field Attendance → Muster → Check in a guard.** ![(1) Muster, (2) Check in a guard](/docs-images/guide/muster-check-in-guard.webp) 2. Type the guard's **mobile number** and press **Find**. Spaces, dashes, a leading 0 or +91 don't matter. Only people at your own sites are found. If two records share the number, pick the right one. ![(1) the guard's mobile number, (2) Find](/docs-images/guide/assisted-find.webp) 3. Check the **name**, **post** and **shift**, and today's status. 4. Optionally add a **note** (e.g. *No smartphone, checked in at the gate*). 5. Press **Check in **. If **Photo at check-in and check-out** is on, the back camera opens: take a photo of the guard's face. With the rule off, the **Photo of the guard** switch adds one anyway. ![(1) the right person, (2) your location is recorded, (3) Check in](/docs-images/guide/assisted-confirm.webp) ![The guard's photo on the back camera](/docs-images/guide/assisted-photo.webp) ![Checked in by the supervisor](/docs-images/guide/assisted-done.webp) 6. At the end of the shift, open it again with the same number. The button now reads **Check out **. You can also open a guard's row in the muster and press **Check in** or **Check out** under **Check in for them**. That skips the number. What is recorded: - The time is the moment you press the button, so **On time**, **Late** and **Half day** work as for the guard's own phone. For a missed punch on an earlier day, use **Correct the times** instead. - The location is **your** location. A check-in from outside the boundary (or with no location) needs a **reason**; it is then saved, flagged **Off-site**, and the reason and your name show on the muster. - The record shows a **By supervisor** tag. In the guard's day, each punch shows **By **. - Not rostered today: the check-in is still saved, flagged **Unrostered**. - Terminated or suspended employees can't be checked in. ## Today **Today** shows, for **All sites** or one site and for any day (use the arrows): - **Approved** (contract headcount), **Deployed**, **Present**, **Shortage** (approved minus present) and **Coverage**. - **Needs attention**: the sites with the biggest gap right now. Click one to open its muster. - **Export DMR** downloads the daily report. ![Today: (1) the day's numbers, (2) the sites most short right now, (3) Export DMR](/docs-images/guide/today.webp) ## Muster **Muster** lists everyone rostered for the chosen day and site: - Totals: **Coverage**, **Late**, **Absent**, **Not marked**, **Flagged** (off-site or unrostered). - Filters: **Everyone**, **On post**, **Late**, **Not marked**, **Absent**, **Off / leave**, **Open shift**, **Flagged**, plus search by name, code, phone or site. - Columns: person, post and shift, in, out, status. - Tick several people → **Mark as…** to record Absent, Leave, Weekly off or Holiday in one go. - **Check in a guard** checks in or out a guard without a smartphone, found by mobile number ([see above](#checking-in-a-guard-who-has-no-smartphone)). - **Export** downloads the list. **Approve day** approves every complete record for the day. ![The muster: (1) filter, e.g. Not marked, (2) search, (3) mark one person, (4) Approve day](/docs-images/guide/muster.webp) Click a person to open their day: - The check-in and check-out **photos**, times and **distance from the site**, and **By ** when a supervisor did the punch. - The **registered face** taken at [Approve & Deploy](/docs/approve-and-deploy), to compare with the check-in photo. - **Check in for them** / **Check out for them** (today, or last night's open shift), for a guard without a smartphone. - Post, shift, worked time and **Late by**. - **Mark as**: Present, Absent, Leave, Weekly off, Holiday. - **Correct the times**: for a missed check-out or a dead phone. A **reason is required**, and the original punches stay on record. - **Approve** the day. Approved days are locked for payroll. ![One person's day: (1) check-in photo and distance, (2) Mark as, (3) Correct the times](/docs-images/guide/muster-record.webp) ## Performance For a month: each person's **attendance %** (days attended ÷ days expected), **on-time %** (check-ins within the grace), late arrivals, hours and missed days. Sort the columns, step between months, and **Export month**. Click a person for their month as a calendar (Present, Late, Half Day, Absent, Missed, Leave, Weekly off) and a **six-month trend**. ![Performance: (1) one person's month, (2) Export month](/docs-images/guide/performance.webp) ## Supervisors A **Supervisor** scoped to one site sees only that site in Today and Muster, on their phone or a laptop. They can mark, correct and approve their team's days, and check in guards who have no smartphone. If they are also linked to an employee record, they get a **My shift** tab for their own attendance. ## Troubleshooting | What the guard sees | Cause and fix | |---|---| | "Your account is not linked to an employee record" | The login's email (or mobile number) doesn't match exactly one employee. Fix the employee's email, then Administration → Add member again with that email. | | "No shift rostered" | No roster assignment for today. | | "Turn on location" / button disabled | Location or camera permission blocked: tap the lock icon in the address bar and allow both. Or the guard is outside the boundary under **Enforce**. | | Distance is always huge | The site has no latitude/longitude, or they are swapped. | | Camera won't open | Use **Use camera app**. | | Supervisor: "No employee at your sites has this number" | The number isn't on the guard's employee record, or the guard isn't deployed at one of your sites. Fix the number under Employees. | | Supervisor: "That employee is outside your assigned sites" | The guard is deployed at a site you aren't assigned to. Ask an admin, or the supervisor of that site. | --- # Leave > Record leave balances, raise leave requests, approve or reject them, and see how approved leave appears in attendance and payroll. Sidebar → **Leave Management** (route `/leave-management`). **Who can do this:** Admin, Ops Manager, HR Manager, Supervisor (`leave.manage`). Field employees can see their own. The page has three parts: - **Leave Review**: counts of requested, approved and rejected leave for a **Period start** to **Period end**, filterable by status. - **Leave Requests**: each request with its status and **Approve** / **Reject** actions. - **Leave Balances**: each person's balance per leave type and period. Leave types: **casual**, **sick**, **earned**, **unpaid**, **other**. ## Set up a leave balance **Leave Balances → Add leave balance**: | Field | Required | Notes | |---|---|---| | Employee | Yes | | | Leave type | | casual, sick, earned, unpaid, other | | Period start / Period end | Yes | e.g. the leave year 1 Jan – 31 Dec | | Opening balance | | Days at the start of the period | | Accrued | | Days earned in the period | | Used | | Days taken | | Adjusted | | Manual corrections (+ or −) | | Closing balance | | Opening + accrued − used ± adjusted | | Notes | | | ![Add leave balance: (1) employee, (2) leave type, (3–4) the period, (5) opening days, (6) Save](/docs-images/guide/leave-balance-add.webp) ![Leave Balances: opening, accrued, used, adjusted and closing days; (1) Add leave balance](/docs-images/guide/leave-balances.webp) ## Raise a leave request **Leave Requests → Add leave request**: | Field | Required | Notes | |---|---|---| | Employee | Yes | A supervisor can raise it on the worker's behalf | | Leave type | | | | Start date / End date | Yes | | | Days requested | | Default 1 | | Reason | | | | Status | | Starts as **requested** | ![Add leave request: (1) employee, (2) leave type, (3) first day, (4) last day, (5) number of days, (6) reason, (7) Save](/docs-images/guide/leave-request-add.webp) ## Approve or reject ![Leave Requests: a requested leave with Approve and Reject](/docs-images/guide/leave-requests.webp) Each **requested** row has **Approve** and **Reject**. An approved request can't be edited or deleted. A rejected request records a rejection reason. ## How it connects - Mark leave days in the [muster](/docs/field-attendance#muster) with **Mark as → Leave**. They then show under **Leave** on the [daily report](/docs/daily-report) and are excused from the attendance %. - Approving a request doesn't change attendance by itself: mark the days in the muster. - [Payroll Prep](/docs/payroll-and-billing) counts every attendance day marked **Leave** as a paid day. Attendance has no separate unpaid-leave status, so for unpaid leave mark the day **Absent** instead. --- # Daily report (DMR) > The Daily Management Report shows, per site and designation, the approved headcount against how many are deployed and present, and the shortage; it can be printed, downloaded as Excel, and seen by the customer. Sidebar → **Daily Report (DMR)** (route `/daily-report`). Facility-management customers expect this report every day: for each site, how many people the contract allows, how many are posted, how many turned up, and where you are short. **Who sees it:** Admin, Ops Manager, HR Manager, Supervisor (their scoped sites), Viewer, and **Client** logins (their own sites only). ## Reading the report Choose the day (arrows, or **Today**) and **All sites** or one site. ![The daily report: the summary cards, then attendance by designation](/docs-images/guide/dmr.webp) The summary cards: | Card | Meaning | |---|---| | Total approved | Contract headcount from Field Attendance → Setup → Approved headcount | | Deployed | People with an active or planned deployment at the site on that day | | Present | People who attended (present, late, half day) | | Shortage | Approved minus present | | Coverage | Present as a share of those on duty (deployed minus weekly off and leave) | **Attendance by designation** has one row per designation: | Column | Meaning | |---|---| | Total approved | Approved headcount for this designation | | Deployed | Deployments whose role title matches this designation | | Present | Attended that day | | Weekly off | Marked weekly off | | Overtime | Extra shifts worked that day, e.g. a guard covering a second shift | | Leave | Marked leave | | NFH | National and festival holidays | | Absent | Marked absent | | Not marked | Rostered but nothing recorded yet | | Shortage | Approved minus present, highlighted when above zero | Two special rows can appear: - **Cover from another post**: someone present at this site without a deployment here, e.g. a reliever. - **Unassigned role**: a deployment with no role title. Expand **What the columns mean** at the bottom of the report for these definitions in the app. For **All sites**, a **Site-wise** list follows, with a search box and **All** / **Short** filters, one expandable block per site. ## Share it - **Print**: a print-friendly layout. - **Download**: **Excel** (one formatted block per site) or **CSV** (one row per site and designation). ![(1) Download, (2) Excel or CSV](/docs-images/guide/dmr-download.webp) - Field Attendance → Today → **Export DMR** gives the same file. - Give the customer their own login (role **Client**, scoped to their client): they open the same page and see only their sites ([Administration](/docs/administration#limit-what-someone-can-see-data-scopes)). - The same report sits in the [Client portal](/docs/client-portal), under the customer's attendance for the period (man-days per site and day by day, with **Export attendance**). The report only goes up to today. **Refresh** reloads it; today's numbers also refresh by themselves while the page is open, as guards check in. ## Getting the numbers right | Problem | Fix | |---|---| | Total approved is empty, "Set an approved headcount" | Field Attendance → Setup → Approved headcount, **for this site** | | Deployed is 0 | No deployment at this site, its start date is in the future, or it's completed or cancelled | | A person sits under "Cover from another post" | Their deployment's role title doesn't match the designation, or they have no deployment here | | Not marked stays high | Supervisors haven't completed the [muster](/docs/field-attendance#muster) | --- # Client portal > The customer-facing view of guard attendance, the daily report (DMR), their sites, billing inputs, compliance follow-ups and service requests, and how to give a customer their own login. Sidebar → **Client Portal** (route `/client-portal`). It is the customer's command view: guard attendance and the daily report for their sites, their client accounts, service sites, billing inputs for a period, compliance items and the service requests they raised. Internal staff see every client; a **Client** login sees only its own. ## Give a customer access 1. [Administration](/docs/administration) → **Add member**: the customer contact's email, role **Client**, a generated password. 2. **Data Scopes → Assign scope**: that member, scope type **client**, target their organisation. 3. Share the sign-in details. A Client login's sidebar shows **Dashboard**, **Clients & Sites**, **Daily Report (DMR)**, **Client Portal**, **Billing Prep**, **Reports** and **Compliance**, all limited to their sites. They never see other customers, identity documents, bank details or police records. ## What the customer sees Pick the period at the top (**Period start** / **Period end**, then **Apply**; it opens on the current month). Everything on the page follows that period and the site chosen in the top bar's site switcher (**All sites**, or one site). ![The customer's Client Portal: (1) the period, (2) Apply, (3) coverage for the period](/docs-images/guide/portal-attendance.webp) ### Attendance for the period The **Attendance** card at the top shows the coverage for the whole period, with the man-days present and short underneath. Below it are two tables: **Site Attendance** has one row per site, counted in man-days (one person on one day = one man-day): | Column | Meaning | |---|---| | Days | Days in the period that were counted | | Present | Man-days present (present, late or half day) | | Absent | Man-days marked absent | | Shortage | Man-days short of the approved headcount | | Days short | On how many days the site had fewer people than approved | | Coverage | Present as a share of the people on duty | **Export attendance** downloads this table as a CSV file, adding the approved and deployed man-days and the period's dates. **Daily Attendance** has one row per day, newest first, across the customer's sites: approved, deployed, present, absent, shortage and coverage. Attendance is read for **at most 31 days at a time**. For a longer period, the latest 31 days are counted and the card says which dates it covers; future days are never counted. ### The daily report (DMR) Below attendance is the **Daily Report (DMR)** for one day: for each site and designation, the approved, deployed and present staff and the shortage, with the same columns as the [Daily report](/docs/daily-report) page. Change the day with the arrows or **Today**. **Download** gives Excel or CSV and **Print** prints the report on its own. When a site is chosen in the site switcher, the report is fixed to that site and its own site picker is hidden. ![The DMR inside the portal, with Download](/docs-images/guide/portal-dmr.webp) ### Everything else - **Client accounts** and **service sites** in their scope, with operating status. - **Billing inputs and invoices** for the selected period: what will be invoiced. These are read-only. - **Compliance** records for their sites: open, in progress, overdue. - **Service requests**: requests raised by the client and their status (open, in progress, closed…), with priority (low, normal, high, urgent). The customer raises one with **Submit request** (e.g. *Guard replacement needed*). ![Raising a service request](/docs-images/guide/portal-request.webp) - The same [daily report](/docs/daily-report) is also on its own page in the sidebar. Attendance and the DMR show counts only. Guard names, punch times, selfies and locations never reach a customer login: both come from the `daily_management_report` database function, which reduces every person to an anonymous key. The Client role does not hold `billing.manage`. A customer login can view and export billing and invoices for its scoped sites but cannot generate, approve, edit, lock, cancel or reissue them. Financial changes stay with internal finance roles. --- # Finance, from attendance to cash > The monthly finance cycle step by step: payroll, billing and GST invoices, client payments, receivables, reconciliation, profitability and the Finance overview. Finance runs once a month, after attendance is approved. Each step feeds the next: 1. **Payroll**: pay your people ([Payroll and billing](/docs/payroll-and-billing) explains the calculation). 2. **Billing and invoices**: bill each client site and issue GST invoices. 3. **Client payments**: record money received and apply it to invoices. 4. **Receivables**: see what is still owed and how late, and send statements. 5. **Reconciliation**: the system checks that billing, invoices and payroll agree. 6. **Profitability**: revenue minus staff cost, by site or client. 7. **Finance overview**: all of the above on one screen. In the pictures, a **red** box is something to click or fill in, and a **blue** box is something to read. The numbers give the order. ## Before the first month Set these up once: - A **verified pay rate and bill rate** on every deployment. - **GST** (CGST, SGST, IGST rates) and **PF / ESI / PT** in [Administration](/docs/administration) › Billing & statutory. While GST is off, invoices carry no tax. - Each worker's statutory profile (wage base, PF/ESI applicable). - Your **billing profile** with **payment terms**: they set each invoice's due date. - Each client's GSTIN, GST treatment and place of supply ([Clients and sites](/docs/clients-and-sites)). - **Two people** who can approve. Whoever generates payroll or billing cannot approve it (maker-checker). **Who can do this:** Payroll: Admin, HR Manager. Billing, invoices and client payments: Admin, Ops Manager. Running reconciliation: Admin, Ops Manager; reviewing findings: Admin. Viewing receivables, reconciliation, profitability and the overview: Admin, Ops Manager, Viewer. ## 1. Payroll In **Finance › Payroll Prep**, set the first and last day of the month and click **Generate**. ![Payroll Prep: (1) first day, (2) last day, (3) Generate](/docs-images/finance/payroll-generate.webp) Read the **Generation summary**: it lists days with no or unverified pay rate, unapproved attendance, and workers without a statutory profile. Fix them and generate again; regenerating replaces the drafts. Check each person's days, overtime, gross, deductions and net (**Breakdown** shows the day-by-day calculation). ![Payroll generated: (1) rows waiting for approval, (2) each person's amounts](/docs-images/finance/payroll-generated.webp) A **different person** then opens the same month and clicks **Approve drafts**. If the preparer tries, SecureForce refuses: "Payroll must be approved by a different person from the preparer." ![The approver: (1) signed in as someone else, (2) Approve drafts](/docs-images/finance/payroll-approve.webp) ## 2. Billing and invoices **Finance › Client Billing & Collections** has four tabs: **Billing Prep**, **Invoices**, **Client Payments** and **Receivables**. On **Billing Prep**, set the month and click **Generate**. There is one row per client site; amounts and GST are calculated by the server from approved attendance and the bill rate on each day. ![Billing Prep: (1) the four tabs, (2) first day, (3) last day, (4) Generate](/docs-images/finance/billing-generate.webp) ![Billing generated: (1) the summary with any warnings, (2) one row per client site](/docs-images/finance/billing-generated.webp) A second person clicks **Approve drafts**, then **Issue invoices** and confirms. Each client site gets one invoice numbered in your financial-year series. Issued invoices can't be edited: correct one with a credit note, or cancel it with a reason and reissue. ![The approver: Approve drafts](/docs-images/finance/billing-approve.webp) ![(1) Approved, (2) Issue invoices](/docs-images/finance/billing-issue.webp) The **Invoices** tab shows every invoice with its payment position (unpaid, part-paid or paid), the amount outstanding and the due date (issue date + payment terms). ![Invoices: (1) outstanding, (2) the invoice number, (3) payment position and due date, (4) View](/docs-images/finance/invoices.webp) ## 3. Client payments Recording a payment has two steps: the **receipt** (money arrived), then its **allocation** (which invoices it pays). One receipt can pay part of an invoice, a whole invoice, or several. Anything not applied stays **unapplied** on the receipt. On **Client Payments**, click **Record payment**, then fill in the client, date, amount, method and UTR or cheque number. You can attach the bank advice. A double click or a dropped connection never records the money twice. ![Client Payments: Record payment](/docs-images/finance/payments-empty.webp) ![Record a payment: (1) client, (2) amount, (3) UTR or cheque number, (4) optional attachment, (5) save](/docs-images/finance/record-payment.webp) Click **Allocate** on the receipt. Click **Fill** next to an invoice to pay it from the receipt, or type a smaller amount for a part payment, then **Apply payment**. You can't apply more than the receipt holds or the invoice owes. ![(1) The receipt, not yet applied, (2) Allocate](/docs-images/finance/payments-recorded.webp) ![Allocate: (1) Fill, (2) planned against available, (3) Apply](/docs-images/finance/allocate.webp) **A cheque bounced?** Click **Reverse** on the receipt and give the reason. Every allocation on it is undone, so its invoices are owed again. The original receipt and the reversal both stay on record. To move money applied to the wrong invoice, open **Allocations** and reverse just that line. ![Reverse a payment: (1) the reason, (2) Reverse](/docs-images/finance/reverse-payment.webp) ![After the reversal: (1) money received, (2) the original and its reversal](/docs-images/finance/payments-final.webp) ## 4. Receivables **Receivables** shows what clients owe today. **Outstanding** is billed but unpaid; **Overdue** is outstanding and past its due date. The **Aging** table splits it by lateness (Not due, 1–30, 31–60, 61–90, 90+ days, and No due date). ![Receivables: (1) outstanding, (2) overdue, (3) aging, (4) every unpaid invoice](/docs-images/finance/receivables.webp) On **Client statement**, pick a client to see every invoice, payment, reversal and credit note with a running balance, and **Export** it to send to them. ![Client statement: (1) the client, (2) the closing balance, (3) Export](/docs-images/finance/client-statement.webp) ## 5. Reconciliation In **Finance › Financial Control › Reconciliation**, pick the month and click **Run checks**. It compares billing, invoices, credit notes and payroll and lists what does not add up. It reports; it never changes your data. Here, October's billing was approved but not yet invoiced: ![Reconciliation: (1) the month, (2) Run checks, (3) the problem, (4) Acknowledge, (5) Resolve](/docs-images/finance/reconciliation-finding.webp) Fix the cause, then an Admin marks the finding **Acknowledged**, **Resolved** or **Dismissed** (with a note). After the invoices were issued, the check comes back clean. Aim for zero open findings before closing a month. ![Reconciliation after issuing: no findings](/docs-images/finance/reconciliation-clean.webp) ## 6. Profitability In **Financial Control › Profitability**, set the range, choose **By site** or **By client**, and click **Run report**. **Gross profit** = net revenue (invoiced, without GST, less credit notes) − direct cost (payroll gross + employer PF/ESI). ![Profitability: (1) by site or client, (2) Run report, (3) gross profit, (4) margin per site](/docs-images/finance/profitability.webp) It is a contribution margin, not net profit: overheads are not included, and revenue is billed, not collected. Revenue whose payroll is not finalized yet is shown as **uncosted** and left out of the margin; **cost coverage** says how much revenue has its cost in. ## 7. Finance overview **Finance › Finance Overview** puts it together. The **Period**, **Client** and **Site** filters at the top drive every card. ![Finance overview: (1) period, (2) client, (3) site, (4) the five key numbers](/docs-images/finance/overview-top.webp) - **Total revenue**, **Payroll cost**, **Gross profit** and **Profit margin** cover the selected period. - **Outstanding receivables** is what clients owe today, with the overdue part. - Further down: the month-by-month chart, revenue by client, profitability, receivables aging, payroll summary, pending approvals, financial control, **Finance alerts** (what needs action now), quick actions, recent invoices and receipts, and the oldest overdue invoices. ![The full overview: (1) month by month, (2) who owes and how late, (3) alerts, (4) shortcuts](/docs-images/finance/overview-full.webp) Payroll counts on the overview cover the whole workspace, because a payroll row belongs to a worker, not a site. If one card can't load, only that card shows an error with **Retry**. A card your role can't see says "access required" instead of showing a zero. ## Good to know - **Every record is counted.** Lists, totals and exports read all rows, however large the workspace. - **Nothing is deleted.** Reversals, cancellations and reviewed findings stay on record with who, when and why. - **"No GST on my invoice"**: GST is off for the workspace. Turn it on in Administration; already issued invoices keep their amounts. - **"Approved by a different person"**: the maker-checker control. Ask a colleague to approve. - The full printable guide, with the same screenshots, is in the repository at `docs/finance-guide/` (Markdown and PDF). --- # Payroll and billing > Generate payroll and server-authoritative billing from approved attendance, then approve, invoice, export and lock each period with GST and audit controls. **Payroll Prep** (route `/payroll-prep`) and **Billing Prep** (route `/billing-prep`) turn attendance into pay and invoices. They work the same way: pick a period, **Generate**, check, approve, export, lock. **Who can do this:** Payroll: Admin, HR Manager (`payroll.manage`). Billing: Admin, Ops Manager (`billing.manage`). Client logins can view and export their own billing and invoices but cannot generate, approve, edit, lock, cancel or reissue financial records. ## How amounts are worked out Each attendance day in the period is followed to its **roster assignment** and from there to the **deployment**, which holds the rates. | Attendance status | Payroll days | Billing service units | | -------------------------------------------------- | ------------ | --------------------- | | present, late | 1 | 1 | | half day | 0.5 | 0.5 | | leave, holiday | 1 | 0 | | absent, rejected/unapproved, weekly off, exception | 0 | 0 | **Payroll**, per employee: - **Days** = sum of days counted. - **Overtime hours** = hours worked beyond 8 in a day (check-in to check-out). - **Gross** = days × **pay rate** + overtime hours × (pay rate ÷ 8 × 1.5). - **Deductions** start at 0 (edit the row); **Net** = gross − deductions. **Billing**, per client and site: the server recomputes service units and amount = units × the **bill rate** effective on each attendance date. The browser sends only the client, site and period. A day without a rate is still counted at ₹0, and generation reports the affected groups: fix the roster or deployment and generate again. **Where the rate comes from.** A day normally takes its rate from the deployment its roster entry belongs to. A day with no roster entry, or whose roster entry isn't linked to a deployment — a **reliever** covering, or a guard nobody rostered — takes it from the worker's own deployment that covers that date: - **Payroll** uses that deployment wherever the day was worked: a worker's pay doesn't depend on which post they covered. - **Billing** uses it only when the day was worked at that deployment's site. A reliever covering at another client's site is not billed at their home site's rate; that day is left out of billing for you to settle with the client. The saved row records how many days were priced this way (`rate_from_deployment_count`). A day that still has no rate (no covering deployment, or the deployment has no rate) is counted at ₹0, and the generation summary reports it: "N attendance records had no pay rate". Fix the deployment and generate again. For taxable billing, the client needs a GST registration status, GSTIN when registered, GST treatment and place of supply. The supplier detail comes from the tenant **Billing Profile**. The client's explicit GST treatment wins over the tenant default; exempt or nil clients are not asked for taxable-only GSTIN, place-of-supply or supplier-state details. There is no silent fallback to a default client tax identity. A taxable invoice is blocked until both sides are valid. ## Generate 1. Set **Period start** and **Period end** (e.g. the 1st to the last day of the month). 2. Press **Generate**. ![Payroll Prep: (1) first day, (2) last day, (3) Generate](/docs-images/guide/payroll-generate.webp) 3. Review the **Generation summary**: rows saved, locked or approved overlaps skipped, manual rows preserved, groups with no approved service units, missing or unverified rates, unapproved attendance still in the period, and GST configuration gaps. ![Generated: (1) the summary, (2) Approve drafts, (3) Export](/docs-images/guide/payroll-generated.webp) **Billing Prep** works the same way, per client and site: ![Billing Prep, generated for the month](/docs-images/guide/billing-generated.webp) Generated rows appear in **Billing Inputs** as **Draft**, with client, site, period, units, taxable value, GST and total. Billing rows are server-generated; use **Manual** only for a service that approved attendance cannot capture. A manual request needs a reason, private evidence (PDF, JPEG, PNG or WebP up to 10 MB) and a different reviewer. Review the request's reason and evidence from its **Review** action before approving it. ## Approve, invoice and lock **Period finalization** moves billing groups through: - **Approve drafts** — the preparer cannot approve their own row. A stale row must be regenerated if attendance, rates, assignments or tax data changed. - **Issue invoices** — creates the numbered invoice from approved billing. - **Lock invoiced** — freezes the period and needs a recorded reason of at least 10 characters. - **Unlock** — needs the separate `billing.period.unlock` permission and a recorded reason. Approval overrides also need a reason of at least 10 characters. Finalization refuses overlapping billing groups, and an active period lock blocks approval, cancellation and invoice issue until it is unlocked. Cancelling an issued invoice requires a reason of at least 10 characters, blocks invoices with active payment allocations, keeps the invoice history, and moves billing to **Reissue ready**. Unlock a locked period before cancelling it. Reissue creates a new invoice while the cancelled invoice remains in the audit trail, and does not require the unlock permission because the period is no longer locked. **Export** downloads the rows for your accounting software. Locked rows can't be regenerated, so lock only when the month is final. ## Before you generate 1. Every day in the period is recorded and **approved** in the [muster](/docs/field-attendance#muster). 2. Every roster entry names the person's **deployment** ([Shifts and roster](/docs/shifts-and-roster)). 3. Every deployment has a **pay rate** and **bill rate** ([Deployment](/docs/deployment)). Workers placed with [Approve & Deploy](/docs/approve-and-deploy) get their pay rate from the approved [salary structure](/docs/hr-approval#the-salary-table) (gross ÷ working days) and their bill rate from the deploy form. 4. Unpaid leave days are marked **Absent**, not **Leave** ([Leave](/docs/leave)). ## Employee Salary **Employee Salary** (`/salary`) is the single workspace for the rest of the salary lifecycle. Its tabs are **Overview**, **Employees**, **Deductions & Loans**, **Statutory**, **Payments**, **Payslips**, **Disputes**, **Approvals**, **Reports** and **Audit**. - **Deductions & Loans** records advances, loans, deductions and reimbursements. They are applied when the payroll period is committed and unbooked amounts carry forward. - **Payments** records a salary disbursement and applies it to finalized payroll rows, partially or across several employees. Reversals keep the audit trail. - **Payslips** generates an immutable payslip per payroll input. Voided payslips can be re-issued. - **Disputes** and **Approvals** record employee queries and approval decisions with author and timestamp. - **Reports** filters by period and site; **Audit** lists the salary-payment audit trail. **Who can do this:** read access follows the salary permissions (`payroll.manage` for HR Manager, `salary_payments.read` for Admin, Ops Manager, HR Manager and Viewer). Recording and reversing salary payments requires `salary_payments.manage` (Admin, Ops Manager). Admin always has full access. --- # Compliance > Track statutory, workforce, client and site deadlines such as licence renewals, PF/ESIC filings and police re-verification, with due dates, owners and alerts. Sidebar → **Compliance** (route `/compliance`). Use it for anything with a due date that you must not miss: PSARA licence renewals, PF/ESIC filings, a client's audit, a guard's police re-verification. **Who can do this:** Admin, Ops Manager, HR Manager, Supervisor (`compliance.manage`); Clients see items for their sites. ## Add a task **Compliance Tasks → Add compliance task**: | Field | Required | Notes | |---|---|---| | Title | Yes | e.g. *Renew PSARA licence for Bengaluru branch* | | Category | Yes | e.g. *Statutory licence*, *PF/ESIC*, *Client audit*, *Police re-verification* | | Status | | **open**, **in progress**, **completed**, **overdue**, **waived** | | Due date | | | | Employee / Client / Site | | Link the task to whoever it concerns | ![Add compliance task: (1) what must be done, (2) by when, (3) Save](/docs-images/guide/compliance-add.webp) ![The task in the list](/docs-images/guide/compliance-list.webp) ## Follow up - Overdue and due-soon tasks raise alerts on the [Dashboard](/docs/dashboard-and-reports) and in **Notifications**. - **Reports** lists open, overdue and due-soon tasks. - Linked tasks also appear on the employee's profile and in the customer's [Client portal](/docs/client-portal). - When it's done, set the status to **completed**; use **waived** when it no longer applies. --- # Dashboard, notifications and reports > The Dashboard, Company Overview, Notifications, Reports and your Profile, the pages that tell you what needs attention. ## Dashboard Sidebar → **Dashboard** (route `/dashboard`), the first page after signing in. - **Total records**, **Field ops** (deployments + attendance) and **Finance rows** (payroll + billing). - **Modules**: counts for Employees, Deployments, Attendance, Payroll Inputs, Billing Inputs and Compliance Tasks. Click one to open it. - **Operations alerts**: near-term compliance, onboarding, attendance, payroll and billing items. - **Refresh** reloads the numbers. Everything is limited to what your role and scope can see; a Client login sees only its sites. ![The Dashboard: (1) menu, (2) workspace, (3) site picker, (4) alerts, (5) help](/docs-images/guide/dashboard-tour.webp) ## Company Overview Sidebar → **Company Overview** (route `/company-overview`): each company in the workspace with the people assigned to it and their platform roles. ## Notifications The bell in the top bar, and the **Notifications** page (route `/notifications`), collect operational alerts: compliance due or overdue, onboarding blocked, documents expiring, attendance exceptions, leave waiting for approval, payroll and billing to finish. ![Notifications](/docs-images/guide/notifications.webp) ## Reports Sidebar → **Reports** (route `/reports`), for a date range: - **Attendance exceptions**: absent, late or exception records that need review. - **Payroll in progress**: draft or approved payroll inputs not yet handed off. - **Billing in progress**: draft or approved billing inputs not yet invoiced. - **Compliance**: open, in-progress, overdue and due-soon tasks. Each list can be downloaded. ![Reports](/docs-images/guide/reports.webp) For attendance itself, use [Field Attendance → Performance](/docs/field-attendance#performance) and the [Daily report](/docs/daily-report). ## Profile Click your name at the top right → **Profile** (route `/profile`): your name, password, the workspace you're in, the modules you can use, and notification preferences. A mobile-number login shows its **Sign-in mobile number** where others show their email. The sun/moon icon in the top bar switches light and dark mode. ![Your Profile](/docs-images/guide/profile.webp) --- # Activity tracking and software security > For office staff on company laptops, the SecureForce agent reports activity (online, foreground app, focused vs idle time) and installed software, and raises alerts for software not on the allowed list. These two pages are for office staff on company laptops, not field staff. Both need the SecureForce Activity Tracker service connected to your workspace. ## Activity Tracking Sidebar → **Activity Tracking** (route `/activity-tracking`). 1. Press **Enable tracking**. This creates a company installer for your workspace. 2. Install it on each company laptop. The laptops register themselves. 3. The page then shows, live (it updates every 15 seconds), every device: who is online, which application is in front, and how the day's hours split between focused work and idle time. Activity rolls up into attendance for desk staff. Each device has a details page (route `/devices/`); a device whose licence was revoked or that was removed shows as not registered. From a laptop's details page an admin can also lock it remotely or put a lost or stolen laptop into Lost Mode — see [Remote lock and Lost Mode](/docs/remote-lock-and-lost-mode). ## Software Security Sidebar → **Software Security** (route `/security-alerts`). **Who can do this:** Admin and IT Admin (`software.manage`). - Company laptops report the software installed on the whole machine every 10 minutes. - Programs on your **Allowed list** are fine. Anything else is **blocked software**: it raises an alert here, and admins and IT admins are emailed. - Manage the allowed list, review alerts and the blocked software from this page. If the page says the tracker backend is missing, the build has no Activity Tracker connection configured. --- # Remote lock and Lost Mode > Lock a company laptop's screen remotely, or put a lost or stolen laptop into Lost Mode so it stays locked behind a full-screen notice until you release it. Both work through the Activity Tracker agent already on the laptop. When a company laptop is left unlocked, misplaced, or stolen, an admin can act on it from SecureForce without touching the machine. This uses the same Activity Tracker agent that already reports activity, so there is nothing extra to install — if the laptop shows up on [Activity Tracking](/docs/activity-tracking), it can be locked. **Who can do this:** workspace **Admin** only. Locking someone's screen is not an HR or manager action, so the buttons do not appear for other roles, and the server refuses the request even if it is sent directly. ## Where to find it Sidebar → **Activity Tracking** → open a laptop (or go to a device page directly at `/devices/`). Admins see a **Remote control** card between the live activity and the Licence section. It has two actions: **Lock screen** and **Turn on Lost Mode**. The card only works for a laptop that is connected to the tracker — one whose status is active or offline. A revoked, blocked, or never-installed laptop shows a short note saying it cannot be reached, because there is no agent there to receive the command. ## How commands reach the laptop Nothing is pushed to the laptop directly, so this needs no open ports and works behind any office firewall or home Wi-Fi. Instead, the laptop's agent asks SecureForce for instructions on every check-in: - **While the laptop is online**, that is about every 15 seconds, so a lock lands within a few seconds. - **While it is offline**, the command waits in a queue and runs the moment the laptop next connects to the internet — even days later. Because of this, the card never claims an action has already happened. A lock shows as *sent* until the agent confirms it ran; Lost Mode shows as *waiting for the laptop to check in* until the agent confirms the lock screen is actually up. ## Lock screen **Lock screen** signs the current user out to the normal Windows lock screen, exactly like pressing `Windows + L` on the laptop. The employee can log straight back in with their usual password or PIN. Use this for the everyday case: someone walked away from an unlocked laptop, or you want to end a session quickly. It is a one-time action, not a state — it does not stop the person using the laptop afterwards. The card keeps a short history of recent locks and whether each one was carried out, so you can confirm a lock actually reached the machine. ## Lost Mode **Lost Mode** is for a laptop that is lost or stolen. It is a state you switch **on** and later switch **off** — it is designed to be reversible so the same laptop works normally again once it is recovered. While Lost Mode is on: - The laptop locks immediately on its next check-in. - After any sign-in attempt it shows a **full-screen notice that cannot be closed**, with the message and contact details you entered. The notice also appears on the Windows sign-in screen itself. - The notice stays up through reboots and with no internet — a stolen laptop that is switched off and booted somewhere with no Wi-Fi still comes up locked. Lost Mode is a strong visible deterrent and a "please return me" notice. It is **not** a kiosk lockdown: it does not block the power button or disk removal, and it cannot survive the hard drive being wiped and Windows reinstalled (nothing software-only can — that needs firmware-level tools built in by the laptop maker). It makes the laptop unusable and unmistakably flagged, which is what deters casual theft and helps return a mislaid machine. ### Turning Lost Mode on 1. Press **Turn on Lost Mode**. 2. Enter the **message** shown on the laptop. A sensible default is filled in; keep it short (up to 300 characters). 3. Optionally add **contact details** — a phone number or desk a finder can reach (up to 120 characters). 4. Confirm. SecureForce then shows you a **one-time unlock code** (see below). > **Write the unlock code down.** It is shown once and never again — SecureForce stores only a scrambled form of it, so it cannot be looked up later. Copy it or note it before closing that dialog. You can change the message by turning Lost Mode on again with new text; this also issues a fresh unlock code and retires the old one. ### Turning Lost Mode off There are two ways to release a laptop, and the laptop works normally again either way: - **From the dashboard** — press **Turn off Lost Mode** on the device's Remote control card. The laptop unlocks on its next check-in. Use this once the laptop is back in safe hands. - **On the laptop with the unlock code** — whoever recovers the laptop types the one-time code into the Lost Mode notice. This is checked on the laptop itself, so it works even with no internet, which is exactly the case where a found laptop is offline. SecureForce is told as soon as the laptop reconnects, so it does not put Lost Mode back on. To stop guessing, the laptop pauses unlock attempts after five wrong codes, and the pause grows with each further wrong try. ## What is recorded Every lock and every Lost Mode change is written to the workspace audit log with who did it and when — including a release done on the laptop with the unlock code. Nothing about the unlock code itself is stored in a readable form. ## A note on consent Remote lock and location-style features belong in your company's device and acceptable-use policy, and employees should be told their company laptops can be locked remotely. SecureForce discloses monitoring on the laptop (the tray app says so), but the policy wording is the employer's responsibility. In India, treat this alongside your obligations under the DPDP Act. ## When it doesn't work - **The laptop never locks.** It has to reach the internet at least once to receive the command. Check it shows a recent check-in on [Activity Tracking](/docs/activity-tracking); a laptop that has been offline for a long time only acts when it reconnects. - **The card says the laptop can't be reached.** Its licence is revoked or blocked, or the agent was never installed. Re-install or unblock it first (see [Activity tracking](/docs/activity-tracking)). - **The lock screen comes back but Lost Mode doesn't show.** The agent needs its tray app running in the signed-in session to draw the full-screen notice; the service restarts the tray automatically, so give it one more check-in. See also [Activity tracking and software security](/docs/activity-tracking) and [troubleshooting](/docs/troubleshooting). --- # Routines > Checklists for setting up a new customer site, bringing on a new guard, and the daily and monthly routines. ## Set up a new customer site (once per site) 1. **Clients & Sites** → add the client (if new), then **Add site** with latitude, longitude and geofence radius. 2. **Field Attendance → Setup → Approved headcount**: pick the site, add each designation and its contract number. 3. **Attendance → Shifts**: make sure the shifts used at the site exist and are **published**. 4. **Administration**: give the customer contact a login (role **Client**) with a **client** scope, and the site supervisor a login (role **Supervisor**) with a **site** scope. ## Bring on a new guard (once per person) 1. **Employees → Add employee** with the email they'll sign in with, or bulk-import a CSV. 2. **KYC Verification → Start a KYC case**: sign off each check, then **Clear for deployment**. 3. **Profile → Start onboarding**: complete the six steps, ending with **Create deployment** (client, site, role title, pay rate, bill rate). 4. **Administration → Add member**: same email, role **Field Employee**. Check it says **Linked to their employee record**, then hand over the sign-in details. 5. **Attendance → Add roster assignment** for each working day, linked to their deployment. 6. On their phone: sign in once, allow camera and location, and install the app to the home screen. ## Every day | Who | What | |---|---| | Guards | **Check in** at the start of the shift and **Check out** at the end, on their phone. | | Supervisors | **Field Attendance → Muster**: mark absentees, leave and weekly offs (**Mark as…**), correct missed punches with a reason, then **Approve day**. | | Operations | **Field Attendance → Today**: work through **Needs attention**; send or download the **Daily Report (DMR)**. | | HR | **Leave Management**: approve or reject requests. Check **Notifications**. | ## Every week - Publish next week's **roster** for every site. - Review **Field Attendance → Performance** for repeated late arrivals and absences. ## Every month 1. Make sure every day of the month is recorded and approved in the muster. 2. **Payroll Prep**: period = the month → **Generate** → check the summary (no "had no pay rate") → **Approve drafts** → **Export** → **Mark exported** → **Lock exported**. 3. **Billing Prep**: the same, then invoice the customer. 4. **Leave Management**: add the month's accrual to the leave balances. 5. **Compliance** and **KYC**: act on anything due or overdue, including police re-verifications. --- # Troubleshooting > Common problems (login not linked, no shift rostered, location or camera blocked, wrong DMR numbers, payroll without rates, locked onboarding or KYC) with the cause and the fix. | What you see | Why | Fix | |---|---|---| | "Your account is not linked to an employee record and has no attendance access" | The login's email (or mobile number) doesn't match exactly one employee's email | Correct the email on the employee record (and make sure no other employee has it), then Administration → **Add member** again with the same email and role. It must say **Linked to their employee record**. | | "Mobile number or password is incorrect" | Wrong password, or that number isn't anyone's login or on their employee record | Check the 10-digit number matches the **Phone** on the employee record. The admin can **Reset password** in Administration → Workspace Members, or add the member again by **Mobile number**. | | A guard forgot their password | Mobile logins have no email for a reset | Admin: Administration → Workspace Members → **Reset password**, then share the new one. | | After signing up, only an "Approval pending" page opens | New workspaces wait for SecureForce to approve them | Wait for approval (the page moves on by itself), or contact SecureForce. If it says **Rejected**, the reason is shown on the page. | | Clients & Sites: **Use current location** says permission was blocked | The browser isn't allowed to share location | Tap the lock icon in the address bar → allow Location, then press it again; or search the place instead. | | Clients & Sites: place search finds nothing | The name is too vague or spelt differently | Search a nearby landmark or the area, then drag the pin to the gate; or paste "lat, lng" from Google Maps. | | Client Portal attendance covers fewer days than the period | Attendance is counted for at most 31 days at a time | Pick a shorter period; the card says which dates were counted. | | "No shift rostered" on the guard's phone | No roster assignment for today | Attendance → **Add roster assignment** for today, at the right site. | | Check in is greyed out, "Turn on location" | Location or camera permission is blocked, or the guard is outside the boundary under **Enforce** | Tap the lock icon in the address bar → allow Location and Camera; press **Refresh location** at the gate. | | "Outside the N m boundary" at the gate | The site's point is wrong, or the radius is too small | Check the site's latitude/longitude (not swapped) and radius in Clients & Sites. | | The distance is always several km | The site has no latitude/longitude, or they are swapped | Clients & Sites → edit the site. | | The camera won't open | The browser can't use the camera | **Use camera app** in the photo window. | | The photo is "too dark" or "blurry" | The quality check failed | **Take again** in better light, or **Use anyway** (marked for the supervisor). | | Daily report: no Total approved | No approved headcount for that site | Field Attendance → Setup → Approved headcount, **after picking that site**. | | Daily report: Deployed is 0 | No deployment at that site on that day | Check the deployment's site, **start date**, end date and status. | | A person under "Cover from another post" | Present without a matching deployment | Make the deployment's **Role Title** match the designation exactly, or add a deployment at that site. | | Payroll: "N attendance records had no pay rate" | The roster entry isn't linked to a deployment, or the deployment has no pay rate | Edit the roster entries (**Deployment**) and the deployment (**Pay Rate**), then **Generate** again. | | Payroll skipped rows as locked or approved | That period is already approved or locked | Generate a different period, or un-approve the drafts first. | | An onboarding step is locked | The step above isn't complete | Complete it; required documents must be uploaded **and** verified. | | Onboarding: "No document types configured" | No document types yet | Employees → **Document Types → Add document type**, or start a KYC case (it adds the standard ones). | | KYC: can't set Aadhaar or PAN to Verified ("Not captured yet") | The number hasn't been entered or is invalid | Type the 12-digit Aadhaar or 10-character PAN in the check, then set **Verified**. | | KYC: **Clear for deployment** is disabled | A mandatory check is outstanding or failed | Hover the button to see which; resolve it. | | A new client or site is missing from a dropdown | Dropdowns load when the page opens | Reload the page. | | A supervisor or customer sees every site | They have no data scope | Administration → **Data Scopes → Assign scope**. | | Bulk import: "Could not find the 'laptop_id' column" | The database is missing a migration | Ask the administrator to apply the latest database migrations. | --- # Glossary > Definitions of SecureForce and facility-management terms such as workspace, site, geofence, deployment, roster, muster, DMR, NFH, KYC, PSARA, DigiLocker and data scope. | Term | Meaning | |---|---| | **Workspace** | One organisation's private area in SecureForce. Nothing is shared between workspaces. | | **Member** | A login in a workspace, with one role. | | **Mobile login** | A login that signs in with a mobile number and password instead of an email, for guards without an email. | | **Approval Pending** | The state of a newly registered workspace until a SecureForce super admin approves it. | | **SecureForce super admin** | Innerverse Tech (IVT) staff who approve or reject new workspace registrations in the Super Admin Console. Not the same as a workspace's own Admin. | | **Man-day** | One person on one day. Client Portal attendance over a period is counted in man-days. | | **Role** | Admin, Ops Manager, HR Manager, Supervisor, Field Employee, Client, IT Admin or Viewer. See [Roles and access](/docs/roles-and-access). | | **Data scope** | A limit on what one member sees: a branch, client, site or employee. | | **Vendor company** | A legal entity of your own group (the service provider). | | **Branch** | An office of yours that services a set of sites. | | **Service line** | What you sell, e.g. manned guarding, housekeeping, technical services. | | **Grade** | A pay band with base pay and an overtime rate. | | **Customer group** | A customer organisation with one or more sister companies, e.g. *ABC Group*. Optional. See [Customer setup](/docs/customer-setup). | | **Sister company** | One company of a customer group, billed separately. Each is a client. | | **Client** | A customer you supply staff to: one billed company. | | **Contract** | An agreement held by one client; it can cover several of that client's sites. | | **Site** | A place where staff work for a client, with a GPS point and radius. | | **Staff category** | The kind of staff a worker is hired into, e.g. Security Guards, Housekeeping, Operators & Technicians. | | **Designation** | A role within a category, e.g. Electrician. Matched by name with the daily report's designations. | | **Mandatory documents** | What a worker must submit before HR approval: the common set, plus what their category and designation add. See [Document rules](/docs/document-rules). | | **Salary structure** | A pre-approved salary: monthly components, gross, and the daily rate payroll uses. See [HR approval](/docs/hr-approval). | | **Maker-checker** | When on, a second HR user must approve what the first prepared. | | **E-signature** | The worker's typed name and drawn signature on the exact contract text, with its SHA-256 fingerprint, time and device. | | **Approve & Deploy** | One action that places an approved worker at a site and hands them to attendance, payroll, billing and the customer. See [Approve & Deploy](/docs/approve-and-deploy). | | **Reliever** | A worker deployed without a fixed shift, rostered day by day. | | **Waiver** | HR's recorded exception that one mandatory document is not needed for one worker. | | **Geofence** | The circle (site point + radius in metres) a guard must be inside to check in. | | **Employee** | One record per person, linked to a login by email or mobile number. | | **Onboarding** | The six-step checklist that takes a new person from profile to deployment. | | **KYC** | Pre-hire verification: identity, address, previous employment, police, medical, training, references, bank. | | **PSARA** | The Private Security Agencies (Regulation) Act, 2005, which sets the checks and training required for private security guards. | | **DigiLocker** | The Government of India app from which documents can be fetched directly from the issuing authority. | | **Deployment** | A person posted at a site, in a role, from a start date, with a pay rate and bill rate. | | **Role title / designation** | The job a person does at a site, e.g. Security Guard, Electrician. The deployment's role title and the approved headcount's designation must match. | | **Pay rate** | Per day, what you pay the person. | | **Bill rate** | Per day, what you charge the client. | | **Shift** | A time slot, e.g. Day 07:00–19:00. | | **Roster / roster assignment** | The plan of who works which shift, where, on which day. | | **Check-in / check-out** | The guard's punches on their phone, with photo and location. | | **Muster** | The day's attendance list for a site, which supervisors complete and approve. | | **Approved headcount** | How many people of each designation the contract allows at a site. | | **DMR** | Daily Management Report: approved vs deployed vs present per designation and site, and the shortage. | | **Shortage** | Approved headcount minus present. | | **Coverage** | Present as a share of those on duty. | | **Weekly off** | A rostered day off. | | **NFH** | National and festival holiday. | | **Cover from another post** | Someone present at a site where they have no matching deployment, e.g. a reliever. | | **Reliever / floater** | A worker who covers others' shifts at different sites. | | **Payroll input** | One employee's pay row for a period: days, overtime, gross, deductions, net. | | **Billing input** | One client and site's billing row for a period: units and amount. | | **PWA** | Progressive web app: SecureForce installed on the phone's home screen. | --- # Agent guide > A compact reference for AI assistants and automation, covering every app route, the role each task needs, the order of operations, task recipes with exact UI labels, and the data model. This page is written for AI assistants that answer questions about SecureForce or help a user operate it. It condenses the rest of the docs into lookups. Fetch the full docs as plain text from `/llms-full.txt`, or one page at `/docs/md/.md`. ## Ground rules - All data belongs to a **workspace**; a user acts in their current workspace (top-bar switcher). - What a user can do depends on their **role** and **data scope**. If a page or button is missing for them, it's a role or scope issue, not a bug. See [Roles and access](/docs/roles-and-access). - UI labels below are exact. Buttons are in **bold**. - Setup has a strict order. When a user is stuck, walk back up the dependency chain in [Core concepts](/docs/core-concepts) before suggesting anything else. ## App routes | Route | Page | Needs | |---|---|---| | `/auth` | Sign in (email or mobile number + password), sign up, Google | Public | | `/accept-invite` | Accept an email invitation | Public (invite link) | | `/docs`, `/docs/` | These docs | Public | | `/approval-pending` | Status of an org admin's workspace registration (pending / rejected) | Signed in, workspace not yet approved | | `/super-admin` | Super Admin Console: approve / reject workspace registrations | SecureForce super admins (`public.platform_admins`) | | `/dashboard` | Dashboard | Any member | | `/company-overview` | Company Overview | tenant.manage (Admin, IT Admin) | | `/employees` | Employee directory, document types, Import CSV | employees (view/manage) | | `/employees/bulk-onboarding` | Bulk onboarding from CSV | employees.manage, onboarding.manage | | `/employees/` | Employee profile | employees view | | `/employees//onboarding` | Six-step onboarding wizard | onboarding.manage | | `/kyc` | KYC case list | kyc view | | `/kyc/` | One KYC case | kyc.manage to change | | `/onboarding` | Onboarding tracker | onboarding view | | `/document-rules` | Staff categories, designations and mandatory document rules | documents.manage for rules; master_data.manage or documents.manage for categories | | `/deployment` | Deployments | deployments view/manage | | `/field-attendance` | My shift, Today, Muster, Performance, Setup | Linked employee (My shift); attendance view (others); attendance.manage or deployments.manage (Setup) | | `/attendance` | Shifts, roster assignments, attendance records | rosters.manage, attendance.manage | | `/leave-management` | Leave requests and balances | leave view/manage | | `/clients-sites` | Customer groups, clients, contracts and sites | master_data.manage to change | | `/hr-approval` | HR approval board and settings; `/hr-approval/` to approve and Approve & Deploy | onboarding.manage or deployments.manage | | `/salary-structures` | The pre-approved salary table | payroll.manage to change | | `/sign/` | Read and e-sign a contract or client NDA | onboarding.manage / deployments.manage, or the worker | | `/employees//id-card` | Printable ID card | employee view | | `/customer-setup` | Wizard: group, companies, contracts, sites, headcount in one transaction | master_data.manage (+ deployments.manage for headcount) | | `/daily-report` | Daily Report (DMR) | headcount view (incl. Client) | | `/client-portal` | Client Portal | Client or staff | | `/payroll-prep` | Payroll Prep | payroll.manage | | `/billing-prep` | Billing Prep | billing.manage | | `/reports` | Reports | View access to attendance, payroll, billing or compliance | | `/compliance` | Compliance tasks | compliance view/manage | | `/notifications` | Notifications | Any member | | `/activity-tracking`, `/devices/` | Activity tracking | tenant.manage (Admin, IT Admin) | | `/security-alerts` | Software Security | software.manage | | `/organization` | Companies, branches, departments, service lines, grades | master_data.manage | | `/administration` | Members, invitations, scopes, numbering, audit | tenant.manage or audit.read | | `/profile` | Own profile | Any member | ## Order of operations (new workspace → first check-in) 1. Sign up (`/auth` → **Sign up**: Full name, Organisation name, Work email, Password → **Create workspace admin**). The workspace is **Approval Pending** (`/approval-pending`) until a super admin approves it at `/super-admin` (users in `public.platform_admins`). 2. `/organization`: company, branch, department, service line, grade. 3. `/clients-sites`: **Add client**, then **Add site** with **Latitude**, **Longitude**, **Geofence radius**. The **Site location** box above them fills latitude/longitude from a place search, **Use current location**, or a tap on the map. 4. `/employees`: **Add employee** with **Email** = their future login email. Optional **Document Types**. 5. `/kyc`: **Start a KYC case** → **Open case** → open the card → set each check **Verified**/**Waived** (Aadhaar and PAN need the number typed) → **Clear for deployment** → **Clear candidate**. 6. `/employees/` → **Start onboarding** → six steps → step 6 **Add deployment** (Client, Site, Role title, Pay rate, Bill rate) → **Create deployment**. 7. `/attendance`: **Add shift** (status **Published**); **Add roster assignment** (Employee, Deployment, Shift, Site, Roster Date = today, Published). 8. `/administration` → **Add member** (same email, role **Field Employee**, **Generate**) → confirm "Linked to their employee record". 9. `/field-attendance` → **Setup**: Location check **Enforce**, photo on, **Save**; Approved headcount: pick the **Site**, **Add designation** = role title, number, save. 10. The guard, on the phone: `/field-attendance` → **Check in** → **Take photo** → **Use photo**. ## Task recipes | Goal | Steps | |---|---| | Give an employee a login | `/administration` → **Add member** → email = employee's email → role → **Generate** → **Add member** → check "Linked to their employee record" → **Copy sign-in details**. | | Limit a supervisor to one site | `/administration` → **Data Scopes** → Member = supervisor, Scope type = site, Scope target = the site → **Assign**. | | Give a customer their daily report | **Add member** with role **Client** → scope type **client** → their client. They open `/daily-report`. | | Fix "not linked to an employee record" | Make the employee's email exactly the login email (unique) → **Add member** again with that email. | | Fix "No shift rostered" | `/attendance` → **Add roster assignment** for today. | | Mark several people absent | `/field-attendance` → **Muster** → tick them → **Mark as…** → Absent. | | Check in a guard with no smartphone | `/field-attendance` → **Muster** → **Check in a guard** → guard's mobile number → **Find** → **Check in** (same again for **Check out**). Needs Supervisor, Operations Manager or Admin; own sites only. | | Correct a missed check-out | **Muster** → click the person → **Correct the times** → enter the time and a **reason** → save. | | Approve a day | **Muster** → **Approve day** (or per person). | | Move a guard to another site | `/deployment` → edit the old deployment: **End Date**, status completed → **Add deployment** at the new site → roster them there. | | Run monthly payroll | `/payroll-prep` → Period start/end → **Generate** → check the summary → **Approve drafts** → **Export** → **Mark exported** → **Lock exported**. | | Import staff from a spreadsheet | `/employees/bulk-onboarding` → **Get the template** → fill → upload → **Import & onboard** → verify documents → **Deploy all verified**. | | Add a deadline | `/compliance` → **Add compliance task** (Title, Category, Due date, links). | ## Data model (main records and links) | Record | Key fields | Links to | |---|---|---| | tenant (workspace) | name, country_code | everything | | tenant_membership | user, role, status | tenant, login | | data_scope | scope_type (all/branch/client/site/employee), scope_id | membership | | employee | employee_code, first_name, last_name, email, phone, status, user_id | company, branch, department, grade, login (user_id) | | client / client_site | name, code; site: geo_lat, geo_lng, geofence_radius_m | branch | | deployment | role_title, starts_on, ends_on, status, pay_rate, bill_rate | employee, client, site, service line | | shift | name, starts_at, ends_at, crosses_midnight, break_minutes, status | site (optional) | | roster_assignment | roster_date, status | employee, deployment, shift, site | | attendance_record | attendance_date, status, check_in_at, check_out_at, check-in geo and photo | employee, roster_assignment, shift, site | | attendance_policy | geofence_mode (off/warn/block), late grace, half-day, radius, time zone, photo, self-service, require checkout | workspace | | site_headcount_requirement | designation, required_count | site | | leave_request / leave_balance | type, dates, days, status / opening, accrued, used, adjusted, closing | employee | | kyc_case / kyc_check / kyc_employment_record | status, valid_until / title, status, reference / company, dates, status | employee, documents | | payroll_input / billing_input | period, days, OT hours, gross, deductions, net, status / units, amounts, status | employee / client, site | | compliance_task | title, category, status, due_date | employee, client, site (optional) | ## Status vocabularies attendance: present, late, half_day, absent, leave, holiday, weekly_off, exception · deployment: planned, active, completed, cancelled · shift: draft, published, locked, cancelled · leave: requested, approved, rejected, cancelled · payroll: draft, approved, exported, locked · billing: draft, approved, invoiced, locked · KYC case: draft, in_review, on_hold, cleared, rejected · KYC check: pending, in_progress, passed (shown as Verified), failed, waived · compliance: open, in_progress, completed, overdue, waived.