Workflows and tasks

Workflows and tasks are the engine of Clover. Together they replace the back-and-forth of email attachments with a defined, trackable way to collect and update information with your trading partners. Understanding how the two relate explains most of what you'll do day to day.

A workflow is a template

A workflow is a reusable template for a business process — collecting insurance certificates, onboarding a vendor, updating product specs. An administrator designs it once as a series of steps and publishes it, after which it's available to the teams it's shared with, or across the whole organization.

A workflow always works on a kind of data. When you author one, you choose the type of object it operates on — a product, a company, or another business process object — and the workflow exposes that object's fields so they can be collected or updated. At run time the workflow is handed an existing instance of that type (or creates one), and the answers flow back into the record. The same mechanism works whether the data is a company, a product, or an arbitrary BPO.

A task is a workflow in motion

A task is Clover's work-distribution mechanism: an instance of a workflow, completed (or not) by an assignee. Every task comes from a workflow, which is why tasks are structured and traceable rather than ad-hoc. When you send a published workflow to a connected company, the recipient gets a task to complete.

The person completing a task moves through its steps in a guided wizard. Depending on the workflow, a step might ask them to read instructions; fill in a form (often pre-filled from their company profile, product data, or another business object such as a chargeback or PO); upload a file; sign a document; or answer a question that decides what comes next. When they finish, the response returns to the company that assigned it. Tasks can also carry a due date.

Where a task is in its life

A task starts as not started, becomes in progress once someone is working it, and ends as completed when the response is submitted. Tasks can also be closed without completion, or wait when something's pending — a task sent to a company that hasn't accepted your connection yet waits until they do.

Who a task goes to

A task is assigned to a specific person or to a department — not to a team, and the difference matters:

A team is a company's internal name for a group of people who do similar work.
A department is Clover's standardized, cross-company name for that kind of group — Finance, Customer Support, and so on. Standard names exist so that a company assigning work to 500 partners can reliably target "Finance" everywhere, even though one partner calls it AP/AR and another calls it Accounting.

So tasks are assigned across companies to a user or a department. When a department is chosen, everyone in that department at the receiving company is notified, and a member must claim the task to take responsibility and respond. (Assigning to an internal team is a planned future capability.)

Sending to many partners at once: campaigns

When a buyer needs the same information from many suppliers — an annual compliance update, say — a campaign assigns one workflow to many connected companies at once, then tracks responses and sends reminders. (Campaigns are a buyer capability; suppliers experience them simply as tasks arriving.)

Why it works this way

Defining work as a published template and deploying it as tasks gives you consistency (every request follows the same shape), traceability (every task has a status and a record), and scale (one workflow, many partners). That's the core of what Clover does.

Business process objects — the data workflows operate on
Connections and the network — tasks flow only between connected companies
Understanding visibility and access — who can create, view, and respond to tasks
Supplier walkthrough: Respond to your first task