Approvals | YunoJuno API Documentation

What is an Approval?

You may require internal sign-off before certain actions can proceed on the platform. This sign-off process is called an approval.

YunoJuno supports approval workflows for two types of events:

Spend requisitions — a spend requisition represents approval for a given budget. It must be reviewed and approved before it can be linked to contracts and acted on.
Contract offers — a contract must be reviewed and approved internally before it is sent to the contractor.

Approvals are entirely optional and configured for your organisation. If you do not use approval workflows, contracts can be offered directly and spend requisitions proceed without requiring sign-off.

Actors

Actor	Who they are	What they do
Hirer (requester)	The hirer who created the contract or spend requisition	Submits the request for approval and receives notifications when it is approved or rejected.
Approver	A designated hirer within the same organisation	Reviews pending approvals and decides to approve or reject them. May be one of several approvers in a sequential chain.
Delegatee	Another hirer temporarily acting on behalf of an approver	Covers approval duties during a defined time window when the original approver is unavailable.
Off-platform approver	A named individual outside the YunoJuno platform	Receives an email invitation to review the approval. Their decision is recorded on the platform even though they act outside it.

What Can Be Approved

Spend Requisitions

When you have spend requisition approval configured, a submitted spend requisition must be approved before it can be linked to job posts or contracts. The approver reviews the details of the request and either approves or rejects it.

Contract Offers

When you have contract offer approval configured, a hirer cannot send a contract to a contractor until one or more internal approvers have signed off on it. The approval happens while the contract is still in draft — the contractor is not notified and cannot see the contract until the approval is complete and the offer is sent.

Only one approval process can be active for a contract at a time.

Approval Routes

You configure one or more approval routes per event type. An approval route defines who needs to approve and how they are selected. There are four types:

Type	How it works
Level-based	Approvers are organised into numbered levels (Level 1, Level 2, etc.). All levels up to a configured threshold must approve, in order. One hirer per group must make the approval. Used when sign-off authority follows organisational hierarchy.
Limit-based	Approval groups are assigned monetary thresholds. The value of the contract or spend requisition determines which approval levels are required — higher-value requests require higher-tier approval groups.
Off-platform	Approval is handled by an external integration.

You may configure multiple routes for the same event type, allowing hirers to select the appropriate route when submitting for approval — for example, routing to different teams depending on the nature of the work.

How an Approval Works

Submitting for Approval

When a hirer submits a contract or spend requisition for approval, they select an approval route. The platform then creates an approval request and sends it to the first approver (or group of approvers) in the chain.

The Approval Chain

An approval request can require one approver or many, in sequence. Each step in the chain is sent to its approver only after the previous step is approved — approvers are notified one group at a time, in order.

At any point there is exactly one step awaiting action. Once that step is approved, the next one is triggered automatically.

Approval Outcomes

Approved — All steps in the chain were approved. The contract can now be offered to the contractor, or the spend requisition can proceed.

Rejected — One step was rejected. The hirer who submitted the request is notified and must decide whether to edit the contract or spend requisition and resubmit.

Resubmitting After Rejection

When a hirer resubmits after rejection, the old approval request is retired and a new one begins from the start. The full history of previous approval attempts is preserved for audit purposes.

Changing the Approval Route Mid-Flight

If a hirer needs to change the approval route while an approval is already in progress — for example, to route to a different team — the current approval is retired and a fresh one begins with the newly selected route. Any approvers on the old route are notified that it has been cancelled.

Read-only Notifiers

It is possible to configure a read-only notification in an approval group. This is useful when you wish to receive a notification that an approval stage has been triggered without having the ability to make an approval decision.

Approval States

The Overall Request

Each approval request moves through the following states:

State	What it means
`NEW`	The request has been created but the first approver has not yet been notified.
`IN_PROGRESS`	At least one approver has been notified and the request is awaiting action.
`APPROVED`	All required approvers have approved. The associated contract or spend requisition is unblocked.
`REJECTED`	An approver rejected the request. The hirer must resubmit or abandon the request.
`SUPERSEDED`	This request was replaced by a newer one (after resubmission or a route change). No further action is possible on this request.

Individual Steps

Within a multi-step approval chain, each step has its own state:

State	What it means
`NEW`	This step has not yet been sent — it is waiting for the previous step to be approved.
`SENT`	This step has been sent to its approver group. An action is needed.
`APPROVED`	An approver actioned this step positively. Either the next step is now sent, or the whole request is complete.
`REJECTED`	An approver rejected this step. The entire request is rejected.

Approval Delegation

An approver who needs to temporarily hand over their approval duties can create an approval delegation. This covers their approval responsibilities for a defined period without requiring them to reassign their role permanently.

How Delegation Works

When an approver sets up a delegation, they specify:

The time window during which the delegation is active (start and end date/time)
Which colleague should cover for them — separately for contract offer approvals and spend requisition approvals

During the active window, the designated colleague receives approval notifications and can action pending approvals on the delegator’s behalf.

Any approvals already in progress when the delegation is created are immediately shared with the delegatee — they do not need to wait for new approvals to be submitted.

Delegation Rules

An approver can only have one active delegation at a time.
A delegation can start immediately or at a specified future time.
Once a delegation has started, its start time cannot be changed — only the end time and the delegatee can be updated.
Cancelling a delegation removes the delegatee’s access immediately, regardless of whether the delegation window has started.

Delegation States

State	What it means
`ACTIVE`	The delegation is set up and the delegatee has (or will have) approval access during the specified window.
`INACTIVE`	The delegation has been cancelled or has expired.

What Happens After Approval

Contract Offers

When a contract offer approval completes successfully, the contract is unblocked and the hirer can send the offer to the contractor. The contractor is then notified and can accept or decline as normal.

If the approval is rejected, the contract remains in draft. The hirer receives a notification explaining the rejection and can edit the contract before resubmitting for approval.

Spend Requisitions

When a spend requisition approval completes successfully, the request is approved and can be linked to contracts.

If the approval is rejected, the hirer is notified and can edit and resubmit the request.