Workflows

When a contract is ready for sign-off, someone has to send it to the right approver, move it to the next stage once they say yes, and tell the requester. Do that by hand on every contract and things slip: approvals sit in an inbox, owners forget to update status, the wrong person gets asked.

Workflows do those steps for you. You tell Pactly when something happens, do this (optionally only if a condition is met), and it runs every time, automatically. For most teams the one thing they configure here is approvals: who signs off on which contracts, in what order, and what happens once they do.

A workflow is not a single object you draw start to finish. It is an automatic reaction with three parts: an event that triggers it, optional rules that decide whether it runs, and the actions that run in response.

• Events are lifecycle moments: a form is submitted, a contract is finalized, an approval is accepted or rejected, a contract is signed.
• Rules are optional conditions: only for a certain category, only when value is above a threshold, only when a risk flag is set. No rule means the action always runs.
• Actions are what Pactly does: request approval, send a notification, change the status, assign an owner, set a property, start a form sequence, call a webhook, or run an AI task.

Every workflow reads the same way: when [event], do [action], but only if [rule]. When a contract is finalized, request approval, but only if its value is $100k or more. Finalizing is the most common trigger: it is the moment an owner marks a drafted contract as ready to move forward, and it is separate from approving or signing, which happen afterward.

You configure all of this on the Workflows screen. The left column lists Workflow Events, grouped into Forms, Contracts, Approvals, and Signatures. Pick an event, click Add action to choose what runs, then open the action’s Rules tab to attach conditions.

Every company starts with a working default, so contracts move through their stages out of the box without you setting anything up. The defaults cover the common path:

You only touch Workflows when you want to change this: routing approvals to specific people, adding or removing an approval step for certain contract types, or adding notifications. Most of this section is about shaping the approval part of that flow.

Workflows run in the background across the whole lifecycle, reacting to each milestone. Intake and finalization feed events in; approvals, status changes, and notifications come out.

Because workflows react to events rather than a fixed schedule, the same event can do different things for different contracts. A finalized NDA can skip approval while a finalized vendor contract routes to Finance and Procurement, all from one “contract finalized” event with different rules attached.

Approvals dominate, but the same event-rule-action engine handles several jobs.

Beyond approvals and notifications, workflow actions can assign an owner, set a contract property, change status, start a form sequence, call an external webhook, or run an AI task such as property extraction. The advanced article covers these.

It is easy to blur approval and signing, but they are separate steps with separate participant lists.

• Approval is the internal sign-off. An approver clicks to approve or reject inside Pactly, checking the contract is okay to proceed.
• Signing is execution. A signer legally signs the document, often someone at the counterparty, through your e-signature provider.

The people who approve and the people who sign are usually different, and you configure them in different places. Each approval request also sends recurring reminders and appears in a recurring reminder digest (daily or weekly, depending on your company’s schedule) until it is resolved, covered in Managing Approval Requests.

One distinction worth getting right early. A form has its own actions that run when it is submitted, such as generating a contract, redirecting the requester, or importing the counterparty’s document. Those are form actions, configured on the form itself.

Workflow actions are a separate system. A form submission can also fire a workflow event (for example, to send a notification), but the contract generation on submit is a form action, not a workflow action.

Approval pathways, routing, managing requests, and advanced actions are covered in the cards above. These cross-section links connect workflows to the rest of the platform:

• Properties & Categories
• Form Actions
• Form Sequences
• E-Signatures