> ## Documentation Index
> Fetch the complete documentation index at: https://kb.mspprocess.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Approvals
> Set up your internal approvers, choose who approves a workflow's requests, let them correct a request first, and see what your team and your client's approver see.
A workflow with approval waits before changing anything in the client's tenant. Your team decides internal requests on Approvals; the client's approver decides external ones from an emailed link. A request routed to a [group](#set-up-approval-groups) isn't emailed: it waits on Approvals for any member, and with Ticketing on, its PSA ticket gets a note linking to Approvals.
## Set up internal approvers
Your internal approvers are your default approver group: a request whose internal approval names no approver goes to them, and without one Core refuses it at submit.
**1. Open the setup**
On Home, click **Set up** next to Set up internal approvers.
**2. Choose the people**
Untick anyone who shouldn't approve, then click **Create**.
Only admins can save it. To change it later, click **Review** on the same step; it edits the same group, which you also manage under **Settings > User groups**.
## Set it up
Choose who approves: None, Internal, External, conditional overrides and letting the approver correct the request (1:19).
**1. Choose a teammate**
On the workflow's **Execution config** tab, choose Internal on the Approval card. Set Approver to Default for your [internal approvers](#set-up-internal-approvers), or to User or [Group](#set-up-approval-groups) and pick who approves.
**2. Or choose the client**
Choose External, then pick each client in the scope dropdown, click **Override** on its Approval card and enter the Client approver name and email. Any email address can approve, without an account.
Base config.
Acme Corp's override.
**3. Let the approver correct the request (optional)**
Turn on **Let the approver edit the request**. It applies to requests submitted after that; with an external approver, anyone holding the link can also browse the client's directory in the request's people pickers until it's answered.
**4. Save**
Click **Save changes**.
To route some requests to a different approval, add a rule under Conditional overrides; the first match wins. Each override has its own Let the approver edit the request switch, off by default, and its approval replaces the default rather than adding to it. Overriding the Approval card for a client copies the base conditional overrides into that client, so later base changes to them don't reach it.
What an approver can correct, when editing is on:
| | Internal | External |
| - | - | - |
| Where | The request on Approvals | The emailed link |
| What | Any answer | Any answer except who receives a password |
| Work email | Regenerated from a corrected name | Regenerated; must be a suggested address not already in use |
| Saved | On Save changes, before approving | On approve; dropped on reject |
Core re-checks corrected answers as it would a new request, keeps any temporary password already shown, and the run uses the corrections.
## Set up approval groups
Route approvals to a group of teammates. Any member can decide a request, and the first decision settles it.
Set up approval groups: create a group, add members and route a workflow's approval to it (1:28).
**1. Create the group**
Go to **Settings > User groups**, click **New group**, enter a Name and an optional Description, and click Create group.
**2. Add members**
Click the group and pick each teammate from **Add a person…**. Changes save as you go; click the cross next to someone to remove them.
**3. Route approvals to it**
Open the workflow from Config. On Execution config, under Approval, choose Internal, set Approver to Group, pick the group and click **Save changes**. Every client inherits it unless you override the Approval card for that client. To send only some requests to the group, use a conditional override and choose Internal, Group and the group under Then.
When a request arrives, it waits on Approvals with the group's name as Approver. Group approvals aren't emailed. If the workflow creates a PSA ticket and Log actions to the ticket is on (the default), the ticket gets an internal note, Awaiting internal approval, linking to Approvals.
The run waits at Approval after noting the ticket.
> [!WARNING]
>
> Before you delete a group, choose a new approver for the workflows that use it. Requests routed to a deleted group can't be approved.
## Approve in Core
Approve a request: open it, correct the details and decide, in Core (1:02).
**1. Open the request**
Go to **Approvals** and click a request. Only its approver, or a member of its group, can decide it.
**2. Check the details**
Request details lists the answers as submitted.
**3. Correct them (optional)**
Click **Edit details**, fix the answers and click Save changes.
After saving: who edited it, with the original answers struck through.
**4. Approve or reject**
Click **Approve**. To reject, click Reject, give a reason and confirm; the run stops.
Filter by Approved or Rejected to see past decisions, who made them and the reason.
## What the client's approver sees
What your client's approver sees: the email, the approval page, correcting the details and the decision (1:03).
External requests don't appear on Approvals.
**1. The email**
It comes from your [approval sender](https://kb.mspprocess.com/core/get-started/add-your-branding.md#send-client-emails-from-your-own-address-optional) and says who requested the change.
**2. The approval page**
View Details opens a page with your branding, on your [public forms domain](https://kb.mspprocess.com/core/get-started/add-your-branding.md#use-your-own-domain-optional) if you've set one, otherwise on Core's own address. There's no sign-in: anyone with the link can answer, and it stops working once someone has.
**3. Correcting the details**
With editing on, Edit turns the details into a form. Who receives a password isn't shown, and anything else they can't change has a padlock.
A Password Reset: where the password goes is locked.
**4. The decision**
They approve or reject, add an optional comment and click Submit. Corrections are saved only if they approve.
**5. Confirmation**
Thank you means the answer reached Core and the run has carried on.
Opening the link again shows one of these:
> [tab] This link isn't available
>
> The request has already been answered.
>
> 
> [tab] Already completed
>
> Someone answered while the page was open.
>
> 
## After the decision
Follow the run on [Executions](https://kb.mspprocess.com/core/use/executions.md): an external request waits at its Client approval step, and a rejected request ends at Not Approved. With Log actions to the ticket on, the PSA ticket also gets these notes:
| Note | When |
| - | - |
| Awaiting internal approval, or Awaiting client approval | The request starts waiting; the client note names the approver's email. |
| Request corrected by the approver | After the decision, if anyone corrected it: who, and each change as `Label: before → after`. |
| Request not approved | The request was rejected. |
## Troubleshooting
> [accordion] “… needs a client approver email — set it on this client's config page.”
>
> The client has no approver. Override its Approval card and enter a Client approver email.
> [accordion] “these changes would need a different approval …”
>
> The corrected answers match a different conditional override. Reject the request and submit a new one with the corrected details.
> [accordion] There's no Edit details button
>
> Editing applies only to requests submitted after it was turned on, and only the request's approver can edit, while it's pending.
> [accordion] “You are not the designated approver for this request”
>
> Only the named approver can decide it. For a group the message reads "You are not a member of the group that can approve this request": add them under **Settings > User groups**.
> [accordion] The client's approver didn't get the email
>
> Check the client's Client approver email and your approval sender. Without a sending profile, ask them to check spam for mail from `app@triggr-app.com`.
Next: [Reports](https://kb.mspprocess.com/core/use/reports.md).
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.