Build the workflow once. Run every request through it.

A request rarely follows one straight line. A routine contract may need a standard review; a higher-risk agreement may need an enhanced approval before both paths come back together for signature and filing.

That logic often sits across intake forms, email, chat, e-signing tools and a spreadsheet somebody has to update afterwards. Each handoff hides status and creates another place where the process can stall.

Fratera brings the route into one visual workflow. Each block has a clear job, each branch expresses a rule and every active request keeps its history from start to outcome.

Start with the path, then add the building blocks

A controlled process can be built from a small set of understandable blocks: forms, approvals, branches, e-signature, notifications, document storage, record updates and an end state. The path between them makes both the normal route and the exceptions visible.

In the contract example below, every request starts with review. A branch sends it through either enhanced or standard approval. Those paths then converge on e-signature before the signed agreement is filed. The workflow is easy to inspect before it is published, and easy to follow once requests are running.

Give every stage an accountable owner

A process should not depend on somebody forwarding an email to the right colleague. Workflow assignments can resolve to the person who started the request, the owner of the subject record, a named person, a work group, a permission holder or a contract stakeholder role.

Suppliers and other outside participants can receive a focused response link without becoming full application users. An optional PIN adds a second shared secret when the process needs it. Internal reviewers still work inside Fratera, where their existing permissions apply.

Let answers change the route

Not every assessment needs every reviewer. Conditional gates can inspect an answer, a record field or a decision and choose the appropriate path. A low-risk supplier can continue to the final review; a supplier handling personal data can be routed to Security; a rejected answer can return to the requester for correction.

This keeps the normal path short without weakening the exceptions. It also makes the rule visible: teams can see why a request took a particular route instead of reconstructing the logic from an email chain.

Design for the work after submission

Submission is usually where the important work begins. A reviewer may need clarification. An assignment may need to move. A due date may pass. Fratera workflows support return, reassignment and manager step-in, with reminder and escalation timing attached to the step.

1. 01
   Collect

   Use staged forms with required questions, conditional sections and a traffic-light question where it helps.

2. 02
   Route

   Send work to the relevant person, group or external respondent and branch when an answer changes the risk.

3. 03
   Review

   Return incomplete work, reassign ownership and escalate overdue steps without losing the request history.

4. 04
   Decide

   Finish with a traffic-light, approved/rejected or custom outcome and set how long it remains valid.

5. 05
   Record

   Save reviewed answers and the outcome back to the relevant vendor or contract fields, with optional human confirmation.

Make the outcome useful—and temporary when it should be

An assessment result should be more than “complete”. It may be Green, Amber or Red; approved or rejected; or a set of labels that matches the organisation’s own policy. It may also be valid for six or twelve months rather than forever.

The workflow can show that result on the subject record and write selected, reviewed answers into structured fields. That means a vendor owner can see the current position without opening the original response, while the workflow run preserves how the decision was reached.

Change the template without rewriting history

Operational processes evolve. A new risk question appears, ownership changes or a routing rule needs to be tightened. Published workflow versions are immutable, and each live request remains pinned to the version that started it. A new version can improve future runs without silently changing the rules under work already in progress.

Before publishing, a draft can be validated and tested against a real vendor or contract without starting work, assigning people or writing fields. Draft with AI can turn a plain-language description into a first workflow in minutes, so teams do not need in-depth technical knowledge to get started. The result remains unpublished until a person checks and publishes it.

One foundation, many procurement decisions

The first obvious uses are vendor onboarding, security and privacy reviews, AI-use assessments, contract intake and annual compliance checks. The common requirement is not a particular questionnaire. It is a repeatable decision involving evidence, ownership and a controlled result.

Bringing those pieces into one workflow reduces the distance between asking a question and acting on the answer. Procurement gets a visible process. Contributors get focused work. Reviewers get the context they need. The vendor or contract record gets a result the wider organisation can use.

See the workflow engine in action

From an AI-assisted draft to human review, branching and approval—then carry assessment outcomes onto the vendor or contract record.

Read the video walkthrough

Describe a supplier review in your own words and let AI draft an editable workflow. An AI step reads the service description and suggests whether personal data is involved. A person reviews that context and confirms the answer. The branch uses the confirmed answer: yes adds data-protection questions; otherwise the request continues to final approval. Both routes rejoin. Assessment outcomes such as Green, Amber or Red can appear on the vendor or contract record, keeping the risk position visible without reopening the assessment. Across Fratera, create approval flows, build assessments, manage purchase orders and put outcomes on the record. Build the workflow once. Run every request through it.