> For the complete documentation index, see [llms.txt](https://kb.logicerp.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.logicerp.com/logic-erp-learning-hub-tutorials-and-best-practices/payroll/payroll-setups/setup-attendance-approval-rules.md). # Setup Attendance Approval Rules **Available on:** Desktop · Web · Phone Navigate to **Payroll Setups** and click on "Setup Attendance Approval Rules". **Setup Attendance Approval Rules** decides who approves an employee's **leave**, **missed-punch**, **short leave** and **comp-off** requests from the attendance app, level by level. Until you add rules, every request uses **COMPANY DEFAULT**: the employee's reporting manager, then HR. COMPANY DEFAULT is created by itself with the first request, at priority 99. ## The screen * **Rules** (top grid): one line per rule — who it is for. * **Levels** (bottom left): the approvers of the selected rule, in order. * **Try it** (bottom right): shows who a real employee's request would go to, using what is on screen, even before you save. ### **Rule columns** | Column | What to enter | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Rule Name** | The rule's name, in capitals. Two rules cannot share a name. | | **Request Type** | **LEAVE**, **MISSED PUNCH**, **SHORT LEAVE**, **COMP-OFF** or **(ANY)**. A comp-off claim follows **COMP-OFF** rules; taking comp-off as a day off is a leave and follows **LEAVE** rules. | | **Branch**, **Department**, **Grade** | Who the rule is for. **(ANY)** = not limited. | | **Priority** | Breaks a tie between two rules that fit equally well: the lower number wins (10 to start, 0 to 999). | | **Inactive** | **Yes** stops the rule being used. Requests already made keep their approvers. | | **Requests** | Filled in by the screen: how many requests have used the rule. | ### **Level columns** | Column | What to enter | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Approver** | **REPORTING MANAGER**, **MANAGER'S MANAGER** (the reporting manager's own manager), **NAMED EMPLOYEE** or **HR** — any working HR user whose HR branch is the employee's branch, or all branches. | | **Named Employee** | Only for NAMED EMPLOYEE: start typing a name and pick the employee from the list. | | **Can Override** | This level may approve or reject while earlier levels are still waiting; the waiting levels are then marked overridden. Not on level 1. | A rule has 1 to 9 levels. ## Which rule applies For each request, the rules that are active, have at least one level and fit the employee and the request type are compared: 1. the rule that names the most of request type, branch, department and grade wins; 2. on a tie, the lowest **Priority** wins; 3. if that also ties, the rule saved first wins. When no rule fits, **COMPANY DEFAULT** is used. It fits everyone, but any rule that names even one condition beats it, whatever the priorities. Only its priority and levels can change; it cannot be deleted or made inactive. > **Example —** Two rules exist: *STORE LEAVE* (LEAVE, branch Delhi) and *DELHI SALES* ((ANY), branch Delhi, department Sales). Neha in Delhi Sales applies for leave: both rules fit, each names two conditions, so the lower **Priority** wins. Her missed-punch request fits only *DELHI SALES* — a LEAVE rule never fits a missed punch. Ravi in Mumbai fits neither, so his requests use COMPANY DEFAULT. ## When a level is skipped A level is skipped when: * it finds nobody in the organisation structure, * it would be the employee themself, or someone who has left, * it is the same person as the level before (the last level not skipped), or * it is an HR level straight after another HR level. If every level is skipped, HR decides. **Try it** shows each skipped level and why. Changing a rule never changes requests already waiting — they keep the approvers they started with. ## Set up a rule ### **Step 1: The rule** * On the blank last line of the rules grid, type the **Rule Name**, then choose **Request Type**, **Branch**, **Department** and **Grade**, and set **Priority**. Finishing the line takes you to its first level. ### **Step 2: The levels** * Add the rule's levels in the levels grid, in order. For **NAMED EMPLOYEE**, pick the employee. * Tick **Can Override** on a later level that may decide before the earlier ones. ### **Step 3: Try it** * Choose **TRY: LEAVE**, **TRY: MISSED PUNCH**, **TRY: SHORT LEAVE** or **TRY: COMP-OFF**, press **Try for Employee...** and pick someone. * It shows the rule they would get, and for each level the approver, who it is today, and the result: **ASKED**, **ASKED (CAN OVERRIDE)**, **SKIPPED** with the reason, or **ADDED** when HR is added because nobody else was found. ### **Step 4: Save** * Press **Save** and confirm. All changes are saved together. > **Example —** Leave in the Delhi store should go to the store manager, then to Priya in HR, but Priya may decide directly when the store manager is away. Rule *DELHI LEAVE*: LEAVE, branch Delhi. Level 1 REPORTING MANAGER; level 2 NAMED EMPLOYEE Priya, **Can Override** ticked. **Try for Employee** on a Delhi salesperson shows level 1 = their manager (ASKED) and level 2 = Priya (ASKED (CAN OVERRIDE)). If Priya approves while the manager has not yet acted, level 1 is marked overridden. ## Deleting * Delete a rule or a level (**F8**) and confirm — *Delete rule '…'?* or *Remove level N?*. It goes when you **Save**. * A rule requests have used cannot be deleted — tick **Inactive** instead. COMPANY DEFAULT cannot be deleted. Closing the screen with changes not saved asks first: **No** goes back so you can save. ## Messages you may see | Message | Why | What to do | | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------- | | Enter the rule name. | A rule's name was cleared | Type the name | | There is already a rule '…'. | Two rules with one name | Use a different name | | Level N: pick the named employee. | Approver is NAMED EMPLOYEE but nobody is picked | Pick the employee | | A rule has at most 9 approval levels. | Adding a tenth level | Remove a level first | | …: add at least one approval level. | On **Save**: the rule has no levels | Add a level | | …, level N: pick the named employee. / …, level N: '…' is not a working employee. | On **Save**: a named approver is missing or has left | Pick someone working, or another approver type | | '…' and '…' apply to the same employees with the same priority; give one a different priority. | On **Save**: two active rules have the same request type, branch, department, grade and priority | Change one priority, or make one inactive | | '…' was used by requests; tick Inactive instead. | Deleting a rule requests have used | Tick **Inactive** | | The company default is used when no other rule fits; it cannot be deleted. | Deleting COMPANY DEFAULT | Change its levels instead | | Employee not found | **Try it**: the employee picked cannot be found | Pick another employee | | There are changes not saved yet. Close without saving? | Closing with changes not saved | **No** goes back so you can Save | | Nothing to save. | Nothing was changed | — | | Modification rights are not available... | On **Save**: your user may only view this menu | Ask for modify rights in User Access | ## On the web The same screen is on the web. On a phone or a narrow tablet, a switch shows the **Rules**, the **Levels** or **Try it**, one at a time. --- # 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://kb.logicerp.com/logic-erp-learning-hub-tutorials-and-best-practices/payroll/payroll-setups/setup-attendance-approval-rules.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.