How to Automate Employee Time-Off Requests with an AI Agent and Human Approval

The real problem is not requesting time off

Asking for time off takes seconds:

“I need three hours off next Monday.”

Or:

“I need three days starting August 18.”

The operational work starts afterward.

Someone needs to understand what kind of request it is, collect the right information, register it somewhere, decide whether approval is needed, notify the manager, record the decision, and tell the employee what happened.

When requests are scattered across messages and emails, a few problems appear quickly:

• there is no single place to see pending requests;
• managers can lose approval messages inside busy inboxes;
• employees may need to ask again for the status;
• historical requests are harder to retrieve;
• reporting becomes manual;
• different managers may follow different processes.

A form can improve data collection, but it still forces the employee to adapt to the form. A conversational AI Agent can do the opposite: understand the employee naturally while still converting the conversation into structured data.

A better model: conversation + structured data + approval logic

The workflow we built combines three elements:

1. An AI Agent for the employee experience
The employee explains what they need naturally. The AI Agent understands the request and asks only for missing information.

2. A Data Table as the process record
Every submitted request becomes a structured row instead of disappearing inside a conversation.

3. Policy-based automation with human approval
Simple requests can move automatically, while requests that require judgment are sent to a human approver.

Tiledesk is designed around this combination of conversational AI, controlled workflow steps, actions, integrations, and human involvement for internal as well as customer-facing operations.

The workflow we built

Here is the high-level architecture:

Employee → AI Agent → Request validation → Data Table → Approval policy → Manager decision → Data Table update → Employee notification

Let’s look at what happens inside it.

1. Identify the employee

The first step identifies who is submitting the request.

For our internal version, employees choose their name from a predefined list. This also assigns useful attributes such as:

• userFullname
• userEmail

In a larger implementation, identity could instead come from authentication, SSO, an employee directory, or another internal system.

2. Understand the type of request

We separate requests into two categories:

• Permesso — time off measured in hours
• Ferie — time off measured in full days

The employee does not always need to know the terminology.

If someone says:

“I need two hours.”

the AI Agent can understand that this corresponds to a Permesso.

If they say:

“I need a full day.”

the Agent can guide them toward Ferie and ask for confirmation.

This makes the interaction more natural than forcing every employee through a rigid form.

3. Collect only the information that is missing

For a Permesso, the Agent needs:

• date;
• number of hours.

For Ferie, it needs:

• starting date;
• number of days.

We use AI Prompt actions to manage this conversation one question at a time. Tiledesk AI Prompt actions can use LLMs as workflow steps, while the visual builder controls what happens before and after the AI interaction.

If the employee starts with:

“I need three days.”

the Agent does not ask again for the duration. It simply asks:

“Da quale giorno?”

If both values are available, the AI returns a controlled value such as:

DataExisted

and the workflow continues.

This is an important design principle: AI understands the messy input, while deterministic workflow logic controls the business process.

4. Show a final summary before submission

Before anything is submitted, the employee receives a final summary.

For example:

Riepilogo della richiesta

• Tipo: Ferie
• Data di inizio: 18/08/2026
• Numero di giorni: 3

The employee can confirm or ask to change the type, date, or duration.

This small confirmation step is useful because natural-language input is flexible, but a business process still needs precise data.

5. Generate a unique Request ID

Once the request is ready, the flow generates a numeric Request_ID.

For example:

20260818143217

We use the current timestamp so every request can be referenced independently.

That ID becomes the key connecting:

• the employee conversation;
• the Data Table row;
• the approval email;
• the approval/rejection workflow.

6. Store the request in a Data Table

Before sending the approval request, Tiledesk inserts the request into a Time Off Requests Data Table.

Our structure includes fields such as:

• Request ID
• Employee name
• Request type
• Leave date
• Number of days
• Number of hours
• Status

The status starts as false/pending.

This is where the workflow stops being “just a conversation.”

The Data Table becomes the operational record of the process: requests can be searched, filtered, updated, and tracked over time.

7. Decide whether human approval is necessary

Not every request needs the same approval process.

A simple policy could be:

• hourly requests → automatic approval;
• one full day → automatic approval;
• multiple days → human approval.

The exact rules depend on company policy.

This is where visual workflow control matters. Tiledesk Conditions can branch a flow based on attribute values, while AI Conditions can be used when the decision depends on semantic understanding rather than a simple deterministic rule.

The point is not to remove humans from the process. It is to reserve human attention for the requests that actually require it.

Human approval directly from email

For requests requiring approval, the manager receives an email containing the request summary and two actions:

Approve
Reject

An optional approval note can also be collected if the workflow requires it.

The interesting part is that the links themselves can carry the attributes needed by the next Tiledesk flow.

A simplified pattern looks like this:

https://api.tiledesk.com/v3/webhook/YOUR_WEBHOOK_ID
?decision=approve
&request_id={{Request_ID}}

The rejection link uses the same webhook:

?decision=reject
&request_id={{Request_ID}}

There is no need to maintain separate approval and rejection endpoints.

The webhook flow reads:

{{webhook_query_params.decision}}
{{webhook_query_params.request_id}}

and immediately knows both what happened and which request should be updated.

Additional attributes can also be included when useful:

&request_type={{TypeOfRequest}}
&date={{DateOfRequest}}
&days={{NumberOfDays}}
&hours={{TimeOfRequest}}

When creating the links inside HTML email, query parameters are separated using &.

For production workflows, we recommend keeping URLs as lean as possible and avoiding sensitive information when it is not necessary. A unique request ID is usually the safest reference for retrieving the remaining data.

What happens after the manager clicks

The approval link triggers a second Tiledesk flow (Webhook Flow).

That flow:

1. reads the decision;
2. reads the Request ID;
3. identifies the corresponding request;
4. updates its status;
5. sends an email to the employee.

If approved, the employee receives something like:

Your time-off request has been approved.

The corresponding Data Table row is updated as approved.

If rejected, the employee receives the rejection notification and the request remains recorded accordingly.

The entire lifecycle is therefore connected:

request → record → decision → update → notification

without someone manually copying information between chat, email, and a spreadsheet.

Why we built it for ourselves first

The original idea came from a client request.

But once we mapped the process, it became clear that this was also a workflow we could use internally.

That is one of the useful aspects of an AI Agent builder: the same building blocks can be applied to many operational processes.

Tiledesk combines a no-code drag-and-drop builder with AI steps, workflow actions, integrations, and human control, specifically so teams can automate real processes without turning every new use case into a custom software project.

The same architecture can be adapted to:

• expense approvals;
• purchase requests;
• remote-work requests;
• access requests;
• internal IT requests;
• training approvals;
• equipment requests.

The conversation changes. The underlying pattern stays very similar:

collect → understand → structure → apply rules → involve a human when needed → record the outcome.

That is where AI Agents become more useful than reply-only assistants: they become part of the operating workflow.

Want to see how this could work in your internal processes?

If your team is still managing approvals through scattered emails, chats, and spreadsheets, this is a good example of where a small AI Agent workflow can remove friction without removing human control.

We originally built this from a real client request, then implemented it internally first.

If you are working on a similar process, we would be happy to map the workflow with you and show how it could be implemented in Tiledesk.