> For the complete documentation index, see [llms.txt](https://docs.digit.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digit.org/complaints-management/access/configurator-onboarding-guide/onboard-employees.md). # Onboard Employees ## Overview Employee onboarding is where you create the actual staff accounts who will use the departments, designations, and complaint types you've configured in the previous phases. Phase 4 creates the actual staff login accounts, assigning each employee a department, designation, one or more roles, and the jurisdiction (geographic area) they're responsible for. This is the final onboarding phase; the people created here are who will actually work complaints day-to-day. ## Steps {% stepper %} {% step %} ### Start Phase 4 To begin, click on **Start Phase 4**, then **Download Template**.

{% endstep %} {% step %} ### Add Employees Fill in the details based on the template, upload your filled file. Each row is validated individually against your tenant's real, current departments, designations, roles, and boundaries.

Column	Notes
employeeCode	Optiona- leave blank for auto-generation
name, mobileNumber, emailId	Basic contact details; mobile number is checked against the tenant's configured format
gender, dob	Date of birth format: YYYY-MM-DD
department, designation	Must match codes created in Phase 3 — comma-separate department codes if a designation spans more than one
roles	Must include EMPLOYEE at minimum; add GRO / PGR_LME / DGRO / CSR as appropriate
jurisdictions	Boundary code(s) or name(s) from Phase 2
dateOfAppointment	Employment start date

Rows with problems are flagged with a specific reason before you commit to creating anything.

{% hint style="info" %} **Note:** The above image is illustrative only and does not reflect live or actual data. {% endhint %} Click **Create \ Employees**. A confirmation dialogue appears, asking you to confirm before anything is actually created - this is your last checkpoint before accounts and credentials are generated. After confirming, employees are created one at a time, not all at once - so if one row fails (e.g. a typo'd department code), the rest still go through instead of the entire batch being blocked. {% endstep %} {% step %} ### Download credentials The completion screen shows exactly which employees were created successfully and which failed, with the specific reason for each failure. A **Download Credentials CSV** button exports name, username, password, mobile number, department, and designation for everyone created. {% hint style="info" %} **Note:** Every created employee gets the same default password. Distribute credentials securely, and instruct each employee to change their password on first login. {% endhint %} If some rows failed, use **Re-upload Fixed File** to try again. This re-opens the file picker and sends you back through the Preview step Once this is completed, click **Complete Setup** to finish. This takes you out of Phase 4 and into the final Onboarding Complete summary screen. This summarises everything created across all four phases and provides direct links to the Employee Login and Citizen Portal pages.

{% endstep %} {% endstepper %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.digit.org/complaints-management/access/configurator-onboarding-guide/onboard-employees.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.