Transactions and deal workflows

A transaction in Waafir is a deal on the platform: a specific raise or financing event with a type, a lifecycle, participants, a workflow, and the files that move it forward. The data room stores documents securely; the transaction is the structure that turns those documents into a deal with a beginning, a middle, and a close.

What a transaction is

Every transaction is bound to one organisation and one data room, and carries a type that frames the deal:

The type is not cosmetic. It frames the terms the deal team and participants negotiate, and it travels through the audit trail so the nature of every deal is on the record.

Two views of one deal

The deal team and investors see transactions through different windows, by design.

The deal team sees deals scoped to a data room. A deal-team member always operates inside an active organisation and active data room; their transaction list shows only the deals belonging to the selected data room. A deal is created explicitly against that organisation and data room — it does not float free.

An investor sees deals across organisations. An investor's transaction view sits at the top level of their navigation, outside the data-room selector. It lists every deal they participate in across the platform, each labelled with its data room and organisation so deals from different companies are distinguishable. An investor reviewing three companies' raises sees all three in one place. Investors do not create transactions; that is a deal-team action.

The lifecycle

A transaction moves through a small, explicit set of states:

draft → executing → executed
                  ↘ cancelled

• Draft. The deal is being set up — participants added, files attached, workflow defined. Nothing has gone out.
• Executing. Triggered when the deal team executes the transaction. Invitations go out to all participants and due diligence is formally underway. Moving to executing requires the groundwork in place: at least one participant, at least one file, and the required workflow steps defined.
• Executed. The deal is closed. Reaching this state requires the workflow complete and the participants aligned.
• Cancelled. A deal can be cancelled from any state. Participants are notified, and the transaction is soft-deleted rather than erased, so the history survives.

Each transition is an explicit action, not a side effect. A deal advances because someone moves it, not because time passed.

Participants

Participants are the people on a specific deal. A participant's role on the transaction is separate from their data-room permission. Data-room permission (covered on the permissioning page) decides which documents someone can open; the transaction role decides what they do in this deal:

When the deal moves to executing, invitations dispatch to every participant. Each participant accepts or declines, and that status is tracked on the deal.

Workflow steps

A deal's workflow is a sequence of steps the deal team defines — financial review, legal review, investor approval, document review, or a custom step. A step can require a particular participant role, so a legal-review step is assigned to the legal participant rather than landing on everyone. As steps complete, the next assignee is notified; when every step is done, the deal team is told the workflow is clear. The workflow makes deal progress auditable rather than a vague status update.

The readiness score

The readiness score is a single number indicating how prepared a deal is. It is a weighted roll-up of:

• Q&A completeness — how many of the deal's questions are answered or closed versus still open. This carries the largest single weight, because an investor entering a deal with open questions has the worst diligence experience.
• Knowledgebase coverage — how many curated Knowledgebase entries are published, against a sensible target.
• Files — how many diligence files are attached, against a target.
• Workflow — how many workflow steps are complete.

The score lets the deal team see at a glance whether a deal is genuinely ready to put in front of investors or only feels ready. It also produces concrete recommendations — answer these questions, publish these entries, upload these files — so "improve readiness" is an actionable list. The Q&A and Knowledgebase inputs are described in detail on the Q&A and Knowledgebase page.

The audit trail

Every meaningful change to a transaction — creation, status change, participant added, file attached, workflow step completed — is written to an audit trail with who did it, when, and the relevant detail. This is the record for reconstructing how a deal progressed or who changed what. Consistent with the rest of the platform, the audit trail is deal-team only: part of the deal team's operational view, not something investors see.

Scope of what ships today

This page documents the transaction engine as it works today: the lifecycle, participants, workflows, files, readiness, and audit. Some adjacent capabilities — in-platform e-signatures, on-chain tokenisation, and investor wallets — are on the roadmap, not in the product, and this page deliberately does not describe them as live. Each will get its own documentation when it ships.