PlaysbyMoat8
Back to the library
The workflow guideHR

Prepare a leave request for approval

Collect the details needed for time off. Route the completed request to its approver.

5 implementation stepsIntermediate

How this works

Collect the details needed for time off. Route the completed request to its approver. Use this when time-off requests arrive through informal messages and repeatedly lack dates, leave type or the right approver. The assistant collects a complete request without making the approval decision.

Apply the employee's current policy and work calendar, then route a structured request through the established HR process. A balance check can identify questions, but incomplete accrual data must not become a rejection or an invented entitlement.

Before you start

Applicable leave policy

Confirm entity, location, effective date and policy owner.

Employee calendar

Obtain work pattern, holidays and permitted leave-balance information.

Approval map

Identify the responsible manager and any HR escalation path.

Prepare the inputs

employee_reference
Required

verified employee ID

Use the existing identity process before retrieving a balance.

requested_dates
Required

start, end, timezone and partial-day details

End must not precede start; ambiguous dates need clarification.

leave_type
Required

approved category identifier

Do not infer a sensitive reason when a generic category is sufficient.

policy_and_balance
Required

version, calendar rules and dated balance

Unknown accruals or pending requests must remain visible.

Implementation, step by step

  1. Identify the request

    • Confirm the employee and requested leave category.
    • Collect only details required by policy, avoiding unnecessary medical or family explanations.

    Checkpoint: A scoped request record exists.

  2. Normalize dates

    • Expand the requested interval against the work schedule and holiday calendar.
    • Calculate working days or hours deterministically, including partial days and overnight schedules.

    Checkpoint: The requested duration is reproducible.

  3. Check completeness

    • Compare dates, notice requirements and balance visibility with the applicable policy.
    • Flag conflicts or missing facts without independently granting or denying leave.

    Checkpoint: The request is complete or has specific questions.

  4. Route to the approver

    • Use the verified reporting line and approval rules.
    • Prepare a form or file if the HR connector is unavailable; submitting externally must be within the requested action.

    Checkpoint: The correct approver and submission status are recorded.

  5. Return accurate status

    • Report draft, submitted, pending or decided from the actual HR record.
    • Record manager decisions without paraphrasing pending status as approval.

    Checkpoint: The employee can see the current state and next step.

Decisions along the way

Requested dates span policy changes

Ask HR which rule applies and preserve both policy versions.

Balance is insufficient or stale

Flag for the approver; do not automatically reject.

Request overlaps pending leave

Show the overlap and ask whether to amend or create a separate request.

What you will produce

leave-request.json

JSON

A structured request suitable for HR review.

Include: employee_id · type · start · end · working_units · approver · status

leave-questions.md

Markdown

Questions that prevent complete or correctly routed submission.

Include: missing_fact · policy_reference · owner

Check the result

  • Recompute duration against the employee's actual calendar.
  • Verify the approver using the current reporting line.
  • Check policy version and balance retrieval date.
  • Confirm no status says approved without an authorized decision.

When something goes wrong

Calendar unavailable

Leave duration provisional and request the correct working pattern.

Submission result unknown

Look up the request ID before retrying to avoid duplicates.

Policy wording conflicts

Route the specific conflict to HR and retain the original passages.

A worked example

SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT

Request

Synthetic: prepare a three-day leave request.

Inputs

Employee E8 works Monday-Friday and requests 10-12 August. The local calendar marks 11 August as a holiday; the available balance is five days.

Expected result

Synthetic result: requested working leave is two days, subject to the verified holiday rule. Route to E8's manager with status draft or submitted according to the actual action; do not deduct the balance.

Run a small pilot

Start small

Use routine requests with weekends, holidays and partial-day examples.

Record the baseline

Record missing-field follow-ups and routing corrections in the current process.

Agree success criteria

Agree duration accuracy and completeness targets with HR before wider use.

Stop or revise

Stop automated submission if calendar or approver mapping is unreliable.

Keep the scope clear

  • The assistant cannot grant leave or determine disputed entitlements.
  • Collecting and drafting can proceed locally; submitting or changing HR records follows the user's authorized scope.

Check before using

The authorized manager decides; uncertain policy questions go to HR.

Business activities

  • Support and develop employees

Editorially adapted workflow; not independently tested.

FROM A RECIPE TO YOUR WORKFLOW

Bring the company context together.

This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.

For this recipe: Requested dates · Employee record · Applicable policy

Start with one recurring task, agree which sources to use, and review the first result with your team.

Discuss this workflow

What does your team do?

Choose the recurring work you would like to improve.

A field guide, made for work.

Plays is a curated library of anonymized business workflows. Each recipe explains the inputs, steps, tools, and checks you can adapt to your team. These are editorial guides, not independently tested implementations.

When you share a company website, the guide may read a limited number of public pages on that website. Messages and retrieved page text are sent to our AI provider, NVIDIA, to recommend relevant workflows. Share a general description rather than confidential information.

Saved workflows and selected activities stay in this browser. Your chat history and selected company website are kept in this tab and cleared when you reload or start a new chat. The server does not store conversations. Live source monitoring is not enabled.

If you allow analytics, PostHog receives page views and actions such as workflow saves, skill downloads and link clicks. Random browser and session identifiers connect these actions without identifying you by name. Your choice and browser identifier expire after 90 days; sessions restart after 30 minutes of inactivity or 24 hours. We use local storage, not analytics cookies. Messages, company URLs, search text, full referrers and IP addresses are not sent. There are no person profiles or session recordings. You can decline or withdraw in Analytics settings; Do Not Track and Global Privacy Control keep analytics off.

Read the Plays Privacy Notice ↗