Campaign Workbench

The first thing you see. Every project of one kind is listed here — a project is the folder a piece of work lives in, holding the selections you build, the bundles they produce and the files you import. The left-hand menu has one entry per kind of project the instance is set up for. Click a row to open the project; Add new starts an empty one.

Add new asks for the few things a project needs: a name you will recognise later, an optional category to group it with related work, and a description. Nothing here is permanent — all of it can be edited from the project afterwards.

The project is the hub for everything that follows. Its details are at the top; underneath, the selections still being worked on, the bundles they have produced, and the files imported into the project. The two buttons at the top right are the two ways work starts: build a selection by filtering, or import a list of items from a file.

A selection is a saved set of filters. The wizard asks three questions: where it starts from — empty, from an existing bundle, or from a saved template — what kind of item it works on, and what to call it. Starting from a template copies a set of filters someone has already tuned, which is the usual way a recurring campaign is repeated.

The second step picks the kind of item the selection will produce. What is on offer is decided by the integrations installed on the instance — each one brings its own item types, its own filters and its own exports.

This is where the work happens. Each tab is a group of related filters; setting one narrows the set, and the count at the top tells you how many items are left. Filters that are switched on are highlighted, and the small × on a row clears it again. Nothing is committed until you finalise: until then you can move the boundaries as often as you like and watch the number move.

Finalising turns the selection into a bundle — a fixed list of items you can act on. The advanced dialog is about what should happen when that bundle is refreshed later: whether items that no longer match should be recalled or deleted, and whether items that have started to match should be added. Recall and add new is the usual choice for a campaign that runs for a while.

A bundle is a fixed set of items plus the actions booked against them. The summary at the top counts the items and totals the amounts; the table underneath is one row per action, with how far each has got. Book action adds another; Refresh re-runs the selection behind the bundle using the rule chosen when it was finalised.

Before an action is sent, everything about it can still be changed: its name, the argument it carries — which letter to send, for example — when it should start, and which days of the week it is allowed to run on. Once it has started the same dialog opens read-only, so the settings it ran with stay visible.

Booking asks which items the action applies to, which action to run, what argument it takes and when it may run. The list of available actions and the values each one accepts come from the installed integration, so this wizard looks different on an instance wired to a different source system.

A follow-up is a new bundle made from part of an old one — typically the items an action did not reach, or the ones that came back a particular way. It keeps a link to the bundle it came from, so a campaign that runs in several passes stays readable as one tree rather than a pile of unrelated lists.

The progress table breaks a bundle down by how each item ended up. Ticking one or more rows and pressing Create follow-up carries exactly those items into a new bundle — which is how a second attempt at the ones that did not land is set up.

Every bundle can be written out as a file. The plain item list is always offered; the exports below it come from the installed integration and each shapes the same items differently. Each one can be taken as a spreadsheet, as CSV or as JSON.

The statistics view plots a bundle against time: how many items it holds, what they are worth and how that has changed since the bundle was made. The panel on the right chooses what is plotted and how it is grouped.

Not every bundle is built by filtering; sometimes the list comes from somewhere else as a spreadsheet. Import from file… opens a five-step wizard, and the first step is simply picking the file.

The wizard reads the file's header row and works out which column is which. It shows what it decided and how confident it is; if it has guessed wrong, the mapping can be corrected before anything is read in. View raw shows the first rows of the file exactly as they arrived.

With the columns settled, the values in them are matched against the instance's own data: item references are looked up, and coded values are translated. Anything that cannot be matched is reported here rather than silently dropped.

The last step before the import lands: a summary of what will be created, and the button that turns the file into a bundle you can book actions against. Pressing it moves the wizard on to Done, which confirms the bundle and offers to open it.

A lookup is a list the instance keeps for itself — here, the letters an action can send. Anything an operator needs to maintain without a developer tends to live in a lookup, and any lookup can be given its own entry in the left-hand menu.

Everything the instance does on its own — keeping its copy of the source system current, refreshing bundles, sending booked actions — is a job, and every run is logged here. The list on the left is the runs; clicking one opens its steps on the right. A run that is still going updates as it goes.

Each run breaks into steps, and each step keeps its own log. Clicking a step expands it, which is where you look when a job failed: the step that broke, what it was doing, and the error it reported.

One index for everything that decides how the instance behaves: who may use it, what the selections can filter on, what actions can be booked, what can be exported, and what runs on a schedule. Most of it is set up once when an integration is installed and then left alone.

The accounts that can sign in. The filter separates the people from the service accounts and from anyone whose request for access has not yet been approved.

A single account: its name and address, whether it is approved, and the group memberships that decide what it may do. This is also where a password is reset and where an account is linked to a directory sign-in.

Permissions are not given to people directly — they are given to groups, and people are put in groups. Two groups exist from the start: everyone who signs in belongs to one, and administrators to the other.

The knobs that apply to the whole instance: which database holds the mirrored source data, how dates are shown, how long a value may go unrefreshed before a selection warns you it is filtering on stale data. Each is saved as you leave the field.

Every filter an operator sees on a selection is defined here: what it is called, which group of tabs it appears under, what kind of input it draws, and the query behind it. Installing an integration fills this list in; a site can add its own.

The catalogue of actions. Each one names what the instance should do to the items in a bundle, where the list of allowed arguments comes from, and whether booking it needs a permission of its own.

Every job the instance can run, with how often it should run and whether it is switched on. A job can also be started by hand from here, which is what you do after fixing whatever made it fail.

The exports that appear in a bundle's download dialog. Each names the query that shapes the file and, optionally, the item type it applies to, so a bundle is only offered exports that make sense for what is in it.

An item type is the answer to "what is a bundle a bundle of?" — a case, a debtor, an invoice. It carries the query that reaches the underlying data and the columns a bundle summarises. Integrations bring their own.

A read-only window onto the tables behind the instance, for the times a number on a page needs explaining. It is a diagnostic tool, not a place to change anything.

An integration arrives as a package: the tables it mirrors from a source system, the filters, actions and exports it brings, and the jobs that keep it current. This page lists what is installed, what version, and what is available to install.

A package can be read before or after it is installed: every object it declares, every filter and action it seeds, and the raw definition behind them. Useful when working out why an instance offers a filter that another one does not.

Version, database, which integrations are installed and what the signed-in account is allowed to do. The first page to open when something is behaving differently from another instance.

After new code is deployed the database it works against may need changes of its own. This page checks, says whether anything is outstanding, and runs the upgrade — with a dry run first if you want to see what it would do. When something is outstanding the instance puts itself into maintenance and sends everybody here until it has been run. On an empty server the same page is the first-run wizard that creates the databases and the first administrator. Here the schema is current, which is what an instance should look like after a deployment has settled.