Handling Approvals

UpServe AI employees use many tools on your behalf. Most are safe to run on their own: searching the web, taking notes, organising files. A few are not: installing a new skill, hiring a new AI employee, clicking a “Pay” or “Send” button on an external site. Those land in your chat as an approval card and wait for your call. This page tells you what those cards mean and how to respond.

Why approvals exist

AI employees are capable, but they cannot read your mind. UpServe draws a line between two kinds of actions:

• Safe to just do: read, search, summarise, take notes. The employee runs ahead.
• Worth a second look: anything that touches the outside world, costs money, deletes data, or submits a form. The employee pauses and shows an approval card. Sometimes a question card lets you finish this check by choosing Proceed just this once. Read the explanation under that choice.

This pattern is sometimes called “human in the loop” automation. It keeps the employee moving fast while making sure the high-stakes moves go through you.

Run without approval vs Approval Required

Every tool sits in one of two modes.

• Run without approval: the employee uses it without asking.
• Approval Required: the employee shows you a card each time before running it.

On the web, you can change this in the employee’s detail screen → Permissions tab → Tool Approval Policy section under the Run automation group (the mobile apps still have it in the employee’s Settings screen). When you expand that section, each active tool shows a single button: either Run without approval or Approval Required. Tapping or clicking the button flips that tool’s setting immediately and saves it right away.

The defaults are:

• Approval Required (default): installing a new skill, sharing a large file as a download link, splitting off a sub-task to run separately, requesting access for the employee to call an external service with your stored connection details, POST/PUT/DELETE external API calls, and running a skill that sends a message outside your organization (a text message, an email, a Slack message, a public post, and similar).
• Run without approval (default): web search and reading, note-taking, GET-style API lookups, team chat, creating/updating/deleting a scheduled run, sharing a file made directly from text you typed, and similar read-only or self-contained work.

On top of that, when an employee is driving a computer screen and reaches a risky step it spots itself (a payment confirmation, a “Send”, a consent dialog, a delete button), it asks you about that one specific click, even if the tool is otherwise set to Run without approval.

If a tool’s approval prompt feels unnecessary, tap the button to switch it to Run without approval. The reverse works too: a normally safe tool can be set to Approval Required when you want a closer eye on it. Either way, the setting applies to all runs including scheduled runs and webhook-triggered ones.

What the approval card shows

When an approval is needed, a card slides into the conversation. Read top to bottom and the information lands in the same order you’d actually weigh it:

• Which tool, and what it will do: right at the top, the tool’s name together with a one-line summary of what it’s about to do (the skill’s name and description, the web page it’s about to open, the POST request it’s about to send, and similar). If your employee wrote that sentence themselves, a small “Written by your employee” note appears right below it.
• Where, to whom, what: a few short fields showing where this action actually goes. See Reading the check fields below.
• Who made it: for anything with a publisher, like a skill install, info on who made it follows right below that.
• Why it’s needed: the reason the employee wrote for itself for installing or running it comes next.
• Caution notice: last, if there’s anything about this action worth flagging, it’s called out. When several things are worth mentioning at once, only the single most important one gets the coloured banner; the rest sit underneath as plain, lower-key lines. If there’s nothing to flag, this part doesn’t appear at all. It never just repeats the headline above it.
• Time left to answer: a countdown bar at the bottom. For a card asking “is it OK to do this now” (running code, clicking on a page, and similar), the card closes if you don’t respond in time, and the employee decides on its own whether to continue without that tool or try a different approach. A skill-install card, which asks “is it OK to have this capability,” works differently. See Skill-install approvals don’t just disappear below.

So the card is never missed just because you’ve scrolled past it, a small waiting bar stays pinned just above the message box the whole time it’s pending. It shows what’s waiting and the time left (mm:ss), and tapping Respond now jumps straight to the card.

Once you press Approve or Deny, the card stops being a screen that helps you decide and becomes a record of what you decided, so it automatically collapses to a single line showing the tool and the outcome. Tap or click that line any time to expand it back open. The one exception is a card that expired without an answer: nobody actually decided anything there, and you may still want to judge whether to retry, so it stays expanded.

Reading the check fields

Even when you asked for something yourself, what actually runs can drift from what you asked for: a different site, or a different account. The approval card is the last place to catch that, so below the headline it lays out where the action is going in a few fields.

Each field has one of these labels:

• Where: the site a request goes to, the skill used to send something, the site of the web page being worked on, a connected outside service, and so on
• To whom: who receives it
• Account: the connected outside account this action uses
• What: the kind of request, the name of a file being shared, the kind of send being run, and so on
• How many: how many items are handled at once
• Undo: shows “Cannot be undone” when the action can’t be reversed

Not every field shows up every time. Only the fields that can be stated with confidence appear. If something like an account name isn’t certain, the field is left out rather than showing a wrong value.

A field looks different depending on where its value came from:

What you see	What it means
Just the value	UpServe checked this value directly against what’s actually about to run.
The value followed by “written by your employee”	Your employee filled this in themselves. UpServe hasn’t verified it, so take a second look to make sure it matches what you asked for.
“Couldn’t verify” in faint text	UpServe can’t tell where the action goes (for example, running code or driving a computer screen), and your employee didn’t fill in a value either. Decide based on the headline and what’s under “Show details”.

If a field has both a value UpServe checked and one your employee wrote, the value UpServe checked is the one shown.

Skill-install approvals don’t just disappear

Most approval cards ask “is it OK to do this right now.” Enough time passing can change the situation the card was about (a page that was open, a request that was in flight), so if nobody answers before the timer runs out, the card simply expires and closes.

The behavior below is not yet live as of this document’s last update. Until it ships, a skill-install approval card times out the same as any other approval (after its 1-hour response window), so you’d need to ask the employee to install again.

A skill-install approval asks a different kind of question. “Is it OK to install this skill” gets the same answer whether you tap it now or hours later, and if you change your mind afterward, removing the skill undoes it. So a skill-install card is being changed to not fully die when its timer runs out. Once that ships, the Approve/Deny buttons will be replaced by a standalone Install "OOO" button, and pressing it later, even after you’ve come back to a conversation that has long since moved on, will install the skill exactly as it would have if you’d approved it in time. There will be no need to start a new conversation or ask again from scratch.

On the rare occasion pressing that button doesn’t go through (the install target the card pointed to has since changed, or you don’t have permission to act on that card, and similar), you’ll see the actual reason it failed instead of a generic “please try again.”

If the employee belongs to a team, an install approval that an organization owner (or, on a personal team, the team’s owner) gives on an install card in the team conversation is shared across the whole team, so other team members won’t be asked again when they install the same skill. An install card in a one-on-one chat is also shared across the team when the organization owner (or, on a personal team, the team’s owner) approves it; an install another member approves there applies to that employee only. See Teams for details.

Checking who made a skill

A skill-install approval card shows more than just the name and description. It also shows who made it.

• An Official UpServe skill badge, shown when UpServe itself made the skill.
• By OOO: the maker’s name, shown when it isn’t an official skill.
• Install count: how many times this skill has been installed so far. If nobody has installed it yet, that’s called out too.
• If the name looks suspiciously close to an official skill’s name, the card carries an extra caution notice.

Use this to confirm the skill you’re about to install actually comes from someone you trust, and isn’t a lookalike with a similar name, before you decide whether to approve it.

Hiring an employee isn’t an approval card

Bringing on a new employee isn’t something an existing employee does with a tool. It’s something you do on screen. So there’s no approval card here. Press the Hire button on Home or a team screen and a confirmation dialog appears asking exactly one thing: “Hire a new employee?” Press Confirm and the new employee exists right away.

• That dialog has no timer. Ignore it and nothing happens. Nothing is ever created on its own.
• You don’t pick a name, a job, or specs here. The new employee asks about all of that themselves, in the chat that opens right after hiring.
• One press hires one employee. Need several? Press it again for each.

No approval card appears while the new hire writes their own name, role, and personality from your answers either. Instead a change card lands in the chat showing exactly what changed, with a Revert button that restores the previous content instantly if you don’t like it. See Hire Your First Employee for the full flow.

Scheduled runs go through right away, then tell you what changed

When an employee creates, changes, or removes one of its own scheduled runs (work that runs automatically at a set time), that happens immediately, with no approval card. Instead, a card announcing exactly what changed lands in the chat right after, so you can always see later when a scheduled run appeared, moved, or disappeared.

The one exception: once the employee already has several of its own scheduled runs active, creating one more during a live conversation pauses for an approval card instead, and beyond a certain point it’s blocked outright. During an autonomous run there’s nobody around to ask, so creation is simply refused at that point instead of showing a card. Changing or removing a scheduled run always goes through without approval, regardless of this limit.

A scheduled run you set up yourself is different. While the employee is running on its own (waking up at a scheduled time, doing a self check-in, and similar), it cannot touch a scheduled run you created. Ask for a change directly in chat (“move that reminder to 9am”) and it takes effect right away. This isn’t a case of waiting for your approval: the action is blocked outright from the start. Instead of a card and a timer, the employee simply gets told “I can’t change this on my own. I’ll bring it up next time we talk” and moves on.

Sharing a file: when it needs approval and when it doesn’t

There are two ways an employee hands you a file it produced, and they’re treated differently.

• A file built directly from text it typed: turning table data into a CSV, or notes into a Markdown document. Below a modest size, this goes through without approval, and it’s free.
• A file that already existed: a PDF, image, or archive produced while running code. A typical-sized file goes through without approval. Only a file large enough to incur an extra charge makes the employee explicitly ask for approval. Video is the one exception: it always requires approval, no matter the size.

Either way, it lands in chat as a downloadable file card. The one exception is handing a file between AI employees on the same team: that never leaves the team, so it always goes through without approval.

Messages sent outside your organization get one more check

A skill action that reaches someone outside your organization the moment it runs, or leaves a hard-to-undo mark on an external system (sending an SMS text message, an email, a Slack message, a public post, a calendar invite, and similar) pauses for an approval card right before it runs. The same skill’s read-only or setup-checking actions aren’t affected and keep running on their own.

The card summarizes which skill and which action it’s about to run, and what it’s about to send. Approve if it looks right, or Deny and ask for a different message.

Approve, deny, or let it lapse

The card has two buttons.

• Approve: the employee runs the tool immediately and continues from the result.
• Deny: the employee skips the tool and looks for another way, or asks you again. If you add a short reason, the employee remembers your preference so it won’t propose the same thing again later.

Use the Approve or Deny buttons to make your decision clear.

If you ignore the card, the timer eventually runs out and the card closes itself. The employee learns “the user didn’t respond” and moves on without that tool, or revisits it next time. A short “Employee decided” line then appears below the card, showing what the employee actually did right after it expired: the name of a different tool it used instead, the first sentence of the text reply it gave, or “Stopped without proceeding” if it made no decision at all. A skill-install approval is planned to show something different here: instead of moving on without that tool, the employee will tell you the Install button is still there waiting for you (see Skill-install approvals don’t just disappear above).

Answering a question can actually make something happen

While an employee is working, it sometimes asks you something and shows tappable options. Some of those options don’t just record your answer. Picking one triggers a real action right away. For example:

• “Cancel this task, or keep going?” → picking Cancel actually cancels that task.
• “Mark this as done?” → picking it actually marks the task complete.
• “Pause this scheduled run for a while?” → picking Pause actually pauses the scheduled run, and picking “turn it back on” later actually resumes it.

A question card may offer a choice such as Proceed just this once to approve the current action. If its explanation says the action will run once without an approval card, read the details shown and select it to finish approving that action. You do not need to approve the same action again on a separate card. If the action changes, you will be asked again. This does not automatically allow future actions. If the explanation says it still asks on an approval card, confirm it yourself on that card after making your choice.

If an option is hard to undo (cancelling or deleting something, for instance), tapping it doesn’t fire right away. An “are you sure?” confirmation pops up first. Only confirming there actually carries it out, so a quick, accidental tap can’t trigger something you can’t take back.

Choosing an auto-approve scope

Above the Approve/Deny buttons, an approval card also lets you pick an auto-approve scope. While you’re approving this one request, you can also decide how much further auto-approval to grant for the same action going forward.

• Just once (default): approves only this request. The same action asks again next time.
• Next 5: the same action is auto-approved up to 5 more times without asking. Once those are used up, it asks again.
• For this task: auto-approves the same action for as long as the current task (a task the employee opened) is running. It’s cleared automatically once that task finishes.
• Always: keeps auto-approving going forward. If the action goes unused for a while, though, it expires on its own and asks again next time. A few especially high-risk tools don’t offer this option at all, for safety.

Check Applies to and the note on the card to see what you are allowing. Do not assume that the recipient or content shown for this request limits every future run. Confirm that the displayed scope is one you want to keep allowing.

MCP-connected tools also let you pick how far it reaches

A service you connect through External tools (MCP) (Notion or Slack, for example) often exposes many tools at once, not just one. When you approve one of those tools with a scope other than “Just once,” one more choice appears underneath: who it applies to.

• This tool only (default): applies only to the tool you just approved.
• All of <service name>: applies to every tool this connection exposes. Approve one Notion tool this way, and using a different tool from the same connection later won’t ask again either.

Pick “All of <service name>” and the note under the scope picker updates to “Applies to every tool from the <service name> server,” so you can see exactly what you’re about to grant. This choice only appears for MCP-connected tools. Anything else has only one possible target to begin with.

A repeating send can be narrowed to “just this skill’s this send”

If a “just <skill name> <send type>” option appears for a repeating send, it limits your permission to that skill and send type. Check the duration, target, and explanatory note before choosing. This does not allow all code execution.

Approving many times doesn’t turn into auto-approval by itself

Approving the same action over and over never switches it to “don’t ask again” on its own. Auto-approval only happens when you pick it on the card.

• For some actions, the card offers Always only after you’ve approved them a few times. If you aren’t there yet, the card shows a hint line such as “Approve this N more times to unlock ‘Don’t ask again’”, and that count includes the approval you’re giving right now.
• Once you’ve approved enough, the hint changes to “Choose ‘Always’ and this won’t ask again” and Always becomes available.
• A request you simply left unanswered doesn’t reduce the count. A denial restarts the count from zero.

The “Auto-approved” marker

When an action runs without an approval card because of an Always choice you made, its tool row carries a small Auto-approved marker at the end. It means the action ran without asking, per your approval rules. It isn’t clickable. If you don’t want it, cancel the rule as described below.

Cancelling an auto-approval you already granted

Where you go to see and cancel what’s currently auto-approved differs by platform, but what it’s allowing, and what Revoke does, is the same on web, iOS, and Android.

On web, whenever you have an active auto-approval, a banner appears at the top of the chat showing what’s currently being auto-approved.

• With 2 or more active auto-approvals, a summary line (“N auto-approvals active”) appears at the top of the banner, collapsed by default. Tap the summary line to expand or collapse it; once you expand it yourself, that choice sticks the next time you open the screen.
• Next to the summary line, View all jumps straight to the auto-approvals list on the employee’s Permissions screen.
• Each row listed in the banner has a Revoke button and a Hide (eye icon) button that collapses just that row from the banner’s display. The auto-approval itself stays active while hidden. This only keeps the chat from being cluttered with approval notices. The eye icon next to the summary line hides the entire banner at once.

iOS and Android (mobile) don’t have this banner. Instead, tap the employee’s name (or avatar) at the top of the chat to open the employee menu. If any auto-approvals are active, the Approval Rules row shows how many are currently on. Tap that row to open the Approval Rules screen, where you can see the full list and cancel any item with the Revoke button next to it. Mobile has no hide feature: since this doesn’t sit in the conversation the way a banner does, there’s nothing that needs hiding.

An auto-approval you turn on while chatting directly only applies to that same kind of direct conversation. It does not carry over to scheduled runs or self check-ins that happen without you present, and only kicks back in the next time you’re chatting directly again. Conversely, an auto-approval granted in a context other than direct chat (a scheduled run, for example) shows a small badge on its row naming that context, so you can tell how far the current auto-approval actually reaches.

On web, even if you’ve hidden every row, you can see and manage everything that’s currently auto-approved from the employee’s detail screen → Permissions tab → Run automation group → Active auto-approvals. That list always shows every grant, including ones hidden from the banner, and a hidden one carries a “Hidden from banner” badge. Each row has its own Revoke button, and a Show items hidden from the chat banner button at the top of the screen brings every hidden row back into the banner. This screen stays open even when you don’t have permission to view an organization employee’s auto-approval list, so hiding the whole banner never leaves you without a way back.

Approving the same thing repeatedly gets you a rule suggestion

If a card asks whether to allow an action automatically, review its scope before choosing. It applies only to the narrow action shown on the card. You can Revoke it at any time in Permissions → Active auto-approvals on the web, or in the employee menu’s Approval Rules on the mobile apps.

Approvals during autonomous runs

Employees don’t only work while you’re chatting. They can wake up at a scheduled time, run a self check-in, or be triggered by an incoming webhook, and the same approval may pop up in the middle of that background work. When that happens:

• The card lands in the employee’s chat as usual.
• If you have push notifications on, you’ll get an “Approval needed” alert.
• For scheduled runs, self check-ins, and webhook runs, the wait time is extended automatically, because those runs assume you can’t reply right away. Push notifications are also sent whenever the timeout reaches 10 minutes or more, even on a regular chat session.
• If the approval or question comes from a workspace (a separate line of work the employee opened alongside your main chat), it resolves automatically faster than one in the main chat. This keeps a single workspace from holding up the main chat while it waits for you. The one exception is a question where the employee hands the screen over to you for something it can’t do itself (signing in, entering a verification code, and similar): that waits for you to actually open the workspace, with no shortened timer. See Workspaces to learn what a workspace is.

To make sure you don’t miss these, enable push notifications in Notification Settings .

Common scenarios

1) Installing a new official skill or a skill from a GitHub repository

When the employee decides “this skill would help with my task,” it calls the install tool. The card shows the skill’s name and description plus a short reason for needing it. If you trust the package, Approve; otherwise Deny with a note like “use a different approach this time.”

2) Running code or issuing a command on its machine

When an employee needs to run something directly (converting files, crunching data, calling an external tool), the card shows what it’s about to run and why. Approve if it reads sensibly, or Deny and ask for a different approach.

Hiring an employee isn’t on this list: hiring is a button you press, not a tool an employee calls (see “Hiring an employee isn’t an approval card” above).

3) Reaching a payment or “Send” step on an external site

When an employee is browsing the web and reaches a high-impact button (Post, Pay, Send, Delete, Agree), it asks before clicking. Read the reason on the card, then decide.

4) Exporting the employee’s own work as a reusable skill

When the employee packages what it built into a reusable skill, a skill review card appears, distinct from a regular approval card. On that screen you can edit the name, description, and file list before saving. Saving keeps the skill private to you; it is never made public.

5) Reaching an external service while running code

When the employee needs to call an external service without ever pulling your stored password or connected account into its code-execution environment, it requests a safe pass-through where the connection details are filled in on the server side instead. You’ll see an “Authorize External API Access” card summarizing exactly which account, which address, and what kind of request (read, create, change, and similar) it would be allowed to send. Once approved, that pass-through stays open, so requests within the same scope won’t ask again. Read the card’s summary carefully before approving.

6) The employee proposes changing its AI work computer’s specs

When a task keeps failing from running out of memory, or the employee notices it hasn’t needed its current specs for a while, it shows a card proposing a spec (CPU/memory) change. The card shows the current and proposed specs together with how many SU per minute go up or down. A downgrade proposal also shows the maximum possible savings over a month. Approving it doesn’t take effect right away; the new specs apply starting the next time this employee’s AI work computer starts up.

7) The employee is about to send a text, email, or similar message on your behalf

When an employee is about to text a customer, send an email, or post to Slack or a social account, it pauses for an approval card right before running it. The card summarizes which skill it’s using and what it’s about to send. Approve if the content is right, or Deny and let it know what to send instead.

How the web browser decides what to approve

Before publishing, paying, or deleting, check the target and content on the approval card.

Remember answers to repeated questions

On web, if a card offers to remember an answer, check which employees it applies to before saving. Review saved answers under the employee’s Settings → Rules this employee follows, then choose Remove to stop using one. To change a remembered answer to a repeated question, remove it first and give a new answer when asked again. A changed action can require a new confirmation after approval, so read the new card too.

Advanced

An auto-approval can still require a fresh confirmation if its target or content changes. Check the visibility of public uploads. Individually addressed emails in a batch and writes to a business system may require separate approval for each execution.