Every task, clearly explained

Know what needs you today, then take one clear next action.

Who: Every signed-in person; your role determines the work you see.

1. Read the items needing your attention.
2. Open Inbox to decide, or New request to ask for something.
3. Use My requests to follow the receipt and current owner.

What happens next: Your own work and the next responsible person stay visible.

If something goes wrong: Missing an area? Check which person and organisation you chose. Ask your administrator about roles.

Open approvals and assigned service tasks, then take the action shown for your role.

Who: Assigned approvers, valid stand-ins and the specialist responsible for each service task.

1. Open the item and read its facts and history. Service tasks have their own fulfilment action; for an approval, follow the decision steps below.
2. Approve if complete; return it with a correction request, or reject with a reason.
3. Read the receipt. The next step may still need another person.

What happens next: The decision enters history and the next approver or service team receives the work.

If something goes wrong: Already changed? Refresh and read the latest version before deciding. Approval does not mean payment.

See the current status, owner and complete decision history.

Who: The requester and people authorised for that request.

1. Open a request from your list or its receipt.
2. Read the next owner and timeline; add a useful comment if needed.
3. For waiting leave or expense claims, use Change this request; other kinds can be withdrawn and recreated.

What happens next: A material change restarts approval. The old and replacement references remain linked.

If something goes wrong: For a returned request, read the reviewer’s reason and use the reply form to answer; this resumes the same request. Keep the reference when asking for help.

Ask for time away with dates and coverage understood.

Who: Employees with a leave balance; the approval rule chooses the reviewer.

1. Choose leave type and dates. Check calculated working days and balance.
2. Add the reason and a stand-in where needed.
3. Send once and keep the request receipt.

What happens next: The request waits for approval; approved leave is recorded in the leave ledger.

If something goes wrong: Fix date overlaps or insufficient balance first. If offline, a queued request still needs to reach the server.

Keep entitlements and holidays consistent.

Who: HR and other permitted administrators.

1. Review the leave types and holiday calendar.
2. Enter the entitlement or adjustment with a reason.
3. Check the affected employee’s ledger and balance.

What happens next: Entitlements are traceable entries, rather than a silently overwritten balance.

If something goes wrong: Confirm year, location and leave type before changing a rule. Correct an error with a explained adjustment.

Record approved work on a non-working day.

Who: The employee; the assigned manager reviews the evidence.

1. Enter the day actually worked and describe the work.
2. Send the request with supporting details.
3. After approval, check the compensatory leave entry.

What happens next: An approved entry adds the entitlement; using it is a separate leave request.

If something goes wrong: Avoid duplicate claims for the same day. Check the work date and the applicable rule.

See approved absence today and upcoming leave before arranging cover.

Who: Managers see their reporting line; HR, directors and administrators see the permitted organisation.

1. Read Away today; this section includes approved leave.
2. Review the next eight weeks, grouped by week, and distinguish waiting requests from approved leave.
3. Agree cover with the people concerned. Use Inbox to decide a waiting request; this calendar has no approval controls.

What happens next: You understand recorded absences and pending plans; arranging cover remains a separate conversation.

If something goes wrong: A missing person can be outside your reporting scope. The calendar covers eight weeks and is not a complete historical leave list.

Plan absence without losing team coverage.

Who: Employees see their balances; managers see permitted team absences.

1. Read the balance by leave type.
2. Use Apply for leave or Team leave to plan coverage.
3. Open a request to understand a pending or approved entry.

What happens next: Balances distinguish entitlement and leave already used.

If something goes wrong: A holiday or weekend can change counted days. Ask HR to check the ledger if a balance looks wrong.

Recover eligible money you spent for the organisation.

Who: The spender; approvers review and finance pays separately.

1. Add each expense with date, category, amount and bill.
2. Check the total and bills. Explain missing evidence in the expense description or a comment.
3. Send, then follow approval and payment separately in Money.

What happens next: A receipt starts approval. An approved claim still awaits payment or advance allocation.

If something goes wrong: Check duplicate bills and totals. Keep original evidence; a changed waiting claim starts approval again.

Receive money before approved organisational spending.

Who: The person responsible for the spending.

1. Enter purpose, amount and when the money is needed.
2. Follow the approval, then confirm payment in Money.
3. After spending, submit expenses against the advance and return unused money.

What happens next: Approval, disbursement, expenses and returned money remain separate facts.

If something goes wrong: An advance is not settled just because it was approved or paid. Check the outstanding balance and finance records.

Agree the trip and estimated cost before travelling.

Who: The traveller and the designated reviewers.

1. Enter destination, dates, purpose and estimated cost.
2. Send for approval before committing to the trip.
3. Claim actual expenses afterwards with bills.

What happens next: Travel approval records permission; it does not itself reimburse expenses.

If something goes wrong: Explain changed dates or costs to the reviewer. Check booking and allowance policies separately.

Use the defined allowance rule for eligible days or work.

Who: Eligible employees; permitted reviewers confirm the claim.

1. Choose allowance type and qualifying dates.
2. Check the configured rate, editable quantity/units and total; verify quantity again after changing type.
3. Send and follow the request to approval and payment.

What happens next: The allowance follows the request process and finance records payment.

If something goes wrong: If no rate applies, ask finance about the rule. Do not replace a missing rate with an invented figure.

Keep approved obligations separate from money actually moved.

Who: Finance and other explicitly authorised roles.

1. Open the approved payable and verify recipient and remaining amount.
2. Record actual payment with method, date and reference.
3. Reconcile against external evidence. Linked approved claims allocate to their advance automatically; record and verify unused-money returns separately.

What happens next: Partial payments leave a visible balance; reconciliation and settlement need their own evidence.

If something goes wrong: Correct the reference before recording. Refresh stale records; never use a second payment to retry a lost response.

See claims, advances, payments and what remains outstanding.

Who: Employees see their records; finance sees authorised payment work.

1. Choose expenses, an advance, travel or allowance for the actual need.
2. Read each request’s approval and payment state.
3. Open details to see allocation, returns and reconciliation.

What happens next: You can distinguish waiting approval from approved but unpaid work.

If something goes wrong: Ask finance with the request reference when payment is delayed. Approved, paid and settled are different.

Get a repair, service request or private complaint to the right team.

Who: Staff; private complaints follow restricted committee routing.

1. Choose the kind, place and urgency, then describe what needs fixing.
2. Attach relevant evidence for ordinary reports; anonymous reports do not retain photos.
3. Send and keep the receipt. For an anonymous report, save the one-time tracking code.

What happens next: The assigned team receives the report with a due time. The subject of a complaint is excluded.

If something goes wrong: Lost anonymous codes cannot be recovered from your name. Use Private tracking for the code; avoid unnecessary sensitive details.

Follow an anonymous case without linking it to your account.

Who: The person holding the private tracking code.

1. Enter the exact code given when the report was created.
2. Read the status and permitted conversation; use Send reply while the case is open.
3. Keep the code private for the next visit.

What happens next: The code opens only its associated anonymous case.

If something goes wrong: Check copying errors. A missing code cannot be recovered by looking up your identity.

Carry a report from assignment to a verified fix.

Who: Reporters and the assigned service team; complaints have narrower access.

1. Read the problem, urgency, due time and current owner.
2. The service team records progress and marks the fix.
3. The reporter checks the fix and rates it, or sends it back with an explanation.

What happens next: The timeline preserves the work. An unconfirmed fix can close after three days.

If something goes wrong: Use the case reference for follow-up. Reopen when the claimed fix did not solve the problem.

Bring structured records into the correct organisation.

Who: Permitted store or HR operators for their respective import.

1. Download the supplied template and preserve its column names.
2. Fill it with confirmed identifiers and values, then review the preview errors.
3. Import only corrected rows and check the resulting records.

What happens next: The app validates the rows and reports problems to correct.

If something goes wrong: Fix duplicate codes and references first. Back up before a real import; the demo is fictional data only.

Get needed tools with clear approval and custody.

Who: Staff request; approvers and store staff fulfil their assigned steps.

1. For equipment, enter category, description, reason and needed-by date. For a purchase, also enter quantity and estimate.
2. Send and follow approval from the receipt.
3. Store records issue or procurement, and the receiving person confirms custody.

What happens next: Approval and physical delivery are separate; custody records who holds the item.

If something goes wrong: If stock is unavailable, follow up with store using the reference. An approved purchase is not proof of delivery.

Give a physical item its own record before tracking custody or printing a label.

Who: Store, facilities and administrator roles maintain the register.

1. Choose the item kind and name. For equipment add category and identifying details; for a book use author and ISBN where known.
2. Select location, optional area and actual condition. Add confirmed purchase details; leave the tag blank to generate one or enter an existing unique tag.
3. Choose Register an item and read the receipt. Check the record before issuing it or printing its label; register each physical item separately.

What happens next: The item has a tag and register record. Registration itself does not hand it to a person or record a payment.

If something goes wrong: Check the register before adding a possible duplicate. A rejected tag needs a unique value; changing location clears the area selection, so choose the correct area again.

Attach a readable tag and QR code to each item still in use.

Who: Store, facilities and administrator roles can print labels.

1. Check the displayed tags and names; retired items are excluded from this sheet.
2. Choose Print labels and inspect the browser print preview before printing or saving a PDF.
3. Scan a sample label, confirm it opens the intended item, and attach each label to the matching physical item.

What happens next: A scan opens the item's permitted record; the label does not grant additional access.

If something goes wrong: If the QR address cannot be reached from the scanning device, ask the operator to confirm the app's configured address and regenerate labels before attaching them.

Know what exists, where it is and who is responsible.

Who: Staff see permitted items; store operators maintain stock and custody.

1. Find the item by code, name or QR label.
2. Read custody, location and condition before issue, transfer or return.
3. Record the movement and check the updated history.

What happens next: Each movement remains traceable to the item and person.

If something goes wrong: A missing or damaged item needs an explicit record and follow-up. Do not silently change its holder.

Give people the access their work needs.

Who: Staff request; approvers decide; IT grants or revokes access.

1. Choose system, access level and purpose.
2. Follow approval, then IT’s fulfilment.
3. Check the grant and revoke it when the need ends or a person leaves.

What happens next: Approval does not itself create access in an external system.

If something goes wrong: Ask IT using the request reference. Never place passwords or recovery codes in request comments.

Reserve shared resources without clashes.

Who: Permitted staff and the relevant resource operator.

1. Choose the resource, start and end time, and purpose.
2. Check availability, then create the booking.
3. Cancel when plans change so others can use the resource.

What happens next: Overlapping bookings are refused; a confirmed booking reserves the interval.

If something goes wrong: Pick a different time or resource after a conflict. Verify the date and India time before saving.

Keep arrival, departure and corrections accurate.

Who: Employees; managers or HR review permitted team records. Reception or facilities signs in to open the shared tablet; each worker then uses a personal PIN.

1. Clock in at arrival and clock out at departure.
2. Review the day’s record and ask for a correction if needed.
3. On a shared tablet, finish your action and leave it ready for the next person.

What happens next: Approved corrections enter the history and can affect pay calculations.

If something goes wrong: A missing clock-out requires review. After five wrong PINs, wait five minutes; ask HR if your PIN is unavailable.

Make progress, blockers and the next plan visible.

Who: People assigned reporting work and their permitted reviewers.

1. Choose the correct day and record actual work.
2. Name any blocker and the help you need.
3. Choose Send report, then follow any review comments.

What happens next: The report gives your manager a factual record rather than another follow-up call.

If something goes wrong: If reporting is not assigned to you, the screen may not appear. Ask your manager about the expected routine.

Keep recurring duties dependable and evidenced.

Who: Assigned operators; housekeeping and facilities leads oversee routines.

1. Open your assigned run for the correct day and place.
2. Check each item only after doing it. Use Report a problem for an exception, with a note and optional photo.
3. Finish the run, or report the item you cannot complete.

What happens next: The run shows completion and missed duties to the responsible lead.

If something goes wrong: Do not tick work that was not done. A blocked item needs a reason and, where needed, a help-desk report.

Maintain places, supplies, vendors and scheduled service.

Who: Facilities operators and other authorised administrators.

1. Open the place, supplier, contract or service schedule.
2. Check owner, quantity, due date and current state before updating.
3. Use a help-desk case for a repair and QR labels to identify the place.

What happens next: Routine service and incident work stay connected to their location and owner.

If something goes wrong: A schedule is not proof that service occurred. Record actual completion and follow up overdue work.

Keep a respectful, accurate arrival and departure register.

Who: Reception and permitted staff.

1. Record the visitor, host and purpose at arrival.
2. Confirm that the host knows the guest has arrived.
3. Record departure when the visit ends.

What happens next: The register shows who is still present and whom they came to meet.

If something goes wrong: Correct the host or arrival detail before saving. Review open visits at the end of the day.

Know who does what and who reports to whom.

Who: Staff see permitted directory details; HR manages restricted records.

1. Search by name in English or Hindi.
2. Open the profile or organisation chart to find team and manager.
3. Use the visible work links for requests or records you are allowed to see.

What happens next: You reach the correct person without exposing private employment documents.

If something goes wrong: Ask HR to correct a wrong manager or team. A missing private section can be an intentional permission limit.

Create an accurate employment record and choose the person's starting work arrangements.

Who: HR and administrator roles can add people in their organisation.

1. Enter name and designation, with Hindi versions and contact details where available; choose team, manager and location.
2. Check joining date, employment type and probation. Deliberately choose app sign-in, optional four-digit shared-tablet PIN and whether to start a joining checklist.
3. Choose Add a person, retain the employee-code receipt and open the profile to check the saved record and any joining checklist.

What happens next: A person record and employee code are created; the chosen joining date controls whether the person is joining soon or active. A checklist starts only when selected.

If something goes wrong: Check People before adding a duplicate. Use a different PIN if one is already taken. Adding a record does not set up external IT accounts or a production identity provider.

Keep people, documents, salary terms and letters accurate.

Who: HR and expressly permitted decision makers.

1. Open the correct person and verify organisation and employment state.
2. Record the permitted change, document or letter with its effective date.
3. Review the saved profile or generated letter before use.

What happens next: Changes and issued documents retain their history.

If something goes wrong: Salary terms and pay calculations are separate. Correct data before regenerating a letter; check private file permissions.

Get a reviewed employment document without retyping HR facts.

Who: Employees may request letters; HR issues them. Only authorised readers can open the issued letter.

1. Choose the letter type and explain what you need.
2. Send the request and follow HR review from its receipt.
3. Open the issued letter and check the name, dates and employment details before use.

What happens next: Requesting and issuing are separate actions; the issued letter is linked to its request.

If something goes wrong: Ask HR to correct the source record if a detail is wrong. Do not edit the issued document to bypass the review.

Hand work across HR, store and IT without missed duties.

Who: The assigned checklist owners and permitted HR operators.

1. Open the person’s joining or leaving checklist.
2. Complete each assigned task after the real action, including equipment and access.
3. Review outstanding tasks. The process becomes complete when all its tasks close.

What happens next: Every handover has an owner and completion evidence.

If something goes wrong: A checked box cannot revoke external access or return equipment by itself. Confirm the real action first.

Turn evidence and feedback into a clear development plan.

Who: The employee, assigned reviewer and permitted HR operators.

1. Open the active review cycle and check its due date.
2. Complete your self-review or assigned assessment with examples.
3. Read the final feedback and agree the next improvement actions.

What happens next: The review captures a considered assessment rather than an unexplained score.

If something goes wrong: Ask HR about a missing cycle or reviewer. Use evidence; do not confuse a score with a pay decision.

Thank people with specific evidence of their impact.

Who: Staff nominate; authorised reviewers approve rewards.

1. Choose the person and describe the contribution.
2. Submit the nomination or thanks.
3. Follow approval and any fulfilment shown in the record.

What happens next: Recognition names the contribution and responsible reviewer.

If something goes wrong: Avoid vague praise or duplicate nominations. An approved financial reward may still need payment.

Compare monthly pay calculations and inspect the source of exceptions before the next authorised step.

Who: HR, finance, director and administrator roles for their organisation.

1. Use the previous/next month controls and confirm the displayed month; the sheet includes active people and those serving notice.
2. Review paid days, gross pay, deductions and net pay. Open a person's name for their detailed summary; a dash means no applicable salary structure.
3. Correct salary, attendance or leave through the permitted source screen, then reopen or refresh the sheet. Use Reports and exports for an authorised pay CSV.

What happens next: You have reviewed calculated amounts and totals. The sheet does not initiate bank payment or complete statutory payroll.

If something goes wrong: Check effective dates and unpaid-day inputs before treating a figure as an error. This screen has no Recalculate or direct export button; calculations refresh from the source records.

Check the inputs and exceptions before using a pay calculation.

Who: Employees can see their own summary; HR, finance, director and admin can see permitted people’s sheets.

1. Choose the month and permitted person or sheet; check salary, attendance and leave inputs.
2. Review every exception and correct the underlying source record.
3. Return to the sheet to read the updated calculation. Use Exports for the available pay CSV.

What happens next: The sheet is a calculation; external bank payment and statutory payroll need separate confirmation.

If something goes wrong: Never treat a generated sheet as proof of payment. Verify local payroll rules before real use.

Give the right audience one clear announcement.

Who: Staff read; permitted publishers create and manage notices.

1. Read the notice and its dates.
2. Publish only with a clear title, audience and action if required.
3. Use Remove on an outdated notice so current guidance stays easy to find; its stored record remains.

What happens next: A notice communicates; a policy acknowledgment is a separate action.

If something goes wrong: If proof of reading is required, use Policies rather than assuming a notice was read.

Keep the approved wording, effective date and acknowledgment requirement clear.

Who: HR and administrator roles can create and edit policies.

1. Enter the title, summary and full policy text; provide matching Hindi text where available and check the effective date.
2. Choose whether everyone must accept. When revising an existing policy materially, select This is a new version to require acceptance again when acknowledgment is enabled.
3. Choose Save, then open the policy from Policies to verify its wording, version and effective date; review acknowledgment coverage there when required.

What happens next: The policy is saved. Selecting a new version increments its version; previous acknowledgments remain associated with their earlier version.

If something goes wrong: A normal edit does not automatically create a new version. Decide the version before saving; employees can acknowledge only once the policy is effective.

Keep the approved policy and its version understood.

Who: Staff acknowledge; permitted HR or administrators publish versions.

1. Open and read the current version.
2. Ask about unclear instructions before acknowledging.
3. Confirm reading; publishers check acknowledgment coverage for that version.

What happens next: The acknowledgment belongs to the version you actually read.

If something goes wrong: A new version can need a new acknowledgment. Check the title and version before acting.

Find workload and bottlenecks that deserve action.

Who: Managers and authorised leaders, within their permitted scope.

1. Check the period, organisation and meaning of each figure.
2. Navigate to the relevant work area or Exports to inspect the underlying records before drawing a conclusion.
3. Assign a responsible person and next action for the issue.

What happens next: Figures support decisions; they do not replace the underlying evidence.

If something goes wrong: Counts depend on recorded data and permissions. Check incomplete records before comparing teams.

Share the permitted facts in a usable file.

Who: People authorised for the selected export.

1. Choose the export and period.
2. Download and inspect the columns, count and sensitive fields.
3. Share only with the intended recipient through your approved channel.

What happens next: An export contains the records your role may access; it is not a complete system backup.

If something goes wrong: For recovery use the backup runbook. A CSV does not contain attachments, permissions and all history.

Route new requests to the intended decision makers with clear thresholds and timing.

Who: HR and administrator roles can edit existing rules for their organisation.

1. Read the request kind, matching condition and ordered approval steps before choosing Edit rule.
2. Set the rule name, leave-day or amount threshold, ordered manager/role steps, optional escalation hours and whether the rule is in use.
3. Choose Save changes, review the displayed rule and test a new fictional request at the relevant threshold in a separate practice instance.

What happens next: The existing rule is updated for routing new requests. Its change does not rebuild approval steps already attached to a waiting request.

If something goes wrong: This editor does not add new rule kinds or change rule priority. Check the full set of matching rules and the boundary amount/days before applying an organisation policy.

Find preferences and the organisation settings your role allows.

Who: Anyone signed in; organisation rules require the relevant role.

1. Open Appearance and choose Light or Dark; your choice saves automatically.
2. Open Menu to change language. Organisational controls appear only for authorised roles.
3. Use Home above the title or the Prabandhan logo to return to work.

What happens next: Your preferences apply on this browser. Changing appearance does not change work records.

If something goes wrong: For approval rules or practice-data controls, use their separate help. Ask your organisation administrator if a required setting is unavailable.

Configure who decides and keep the practice environment understandable.

Who: Administrators and the roles permitted for each setting.

1. Review approval kinds, thresholds and responsible roles.
2. Make one deliberate change and test its effect with a fictional request.
3. Use demo reset only when you intend to replace all practice records.

What happens next: Rules affect routing of new work. Reset is a destructive replacement of demo data.

If something goes wrong: Record the rule’s purpose and check a boundary amount. Do not reset the owner’s running database merely to run tests.

Reach the work that changed or needs your attention.

Who: The signed-in recipient.

1. Open Menu, then Notifications. Read the message and open its linked record.
2. Check the record’s current state before acting; mark read when you understand the update.
3. Select Home above the title, use the app logo or navigation to return to work.

What happens next: Reading a notification does not approve, pay or complete the linked work.

If something goes wrong: A notification can describe an earlier state. Use the linked record as the current source of truth.

Use a clear, readable theme in the light you work in.

Who: Anyone signed in; the choice is remembered on this browser.

1. Open Menu, then Appearance. Choose Light or Dark; there is no Save button.
2. Select Home above the title, use the app logo, or use the navigation to return to work.
3. To change language, open Menu and choose हिन्दी or English.

What happens next: The theme applies to every screen and is remembered on this device.

If something goes wrong: If a colour or control is unclear, report the screen and theme. Browser zoom is supported.

Explore work as an employee, manager or service team.

Who: Demo visitors; this person picker is practice sign-in.

1. Choose the fictional organisation and person.
2. Continue as that person; the menu reflects their roles.
3. Open Menu, then Sign out; choose the next person to test a handover.

What happens next: You see the chosen person’s demo work. This is not production identity verification.

If something goes wrong: Ananya Rao demonstrates employee work; Radhika Menon has the director view. Keep real personal data out of this practice instance.

Understand what is saved on the device and what reached the server.

Who: The original person who queued the work, on the same browser.

1. An already-open form can queue work; cold offline navigation shows a generic offline page. Read whether a server receipt exists.
2. Reconnect and return as the original person; use the outbox’s send action.
3. Check each receipt. A rejected item cannot be retried or edited in the outbox: keep its details, send a corrected fresh form, confirm its receipt, then discard the old item.

What happens next: Queued work is device-local until accepted. Changing account must not send another person’s work.

If something goes wrong: Do not clear browser storage with unsent work. A permission or stale-record rejection needs correction, not repeated blind sending.

Learn the task, next owner and recovery path without guessing.

Who: Everyone; this guide is available before sign-in.

1. Search for a task such as leave, payment, visitor or उपकरण.
2. Open the matching instructions and read who may act.
3. Follow the steps, expected result and repair advice.

What happens next: Contextual help on each screen links to the same maintained guide.

If something goes wrong: For technical setup, operations and investor context, use the maintained documentation library in the shared app folder.