Closing, child cases and payments

How to: record the outcome of a finished case

1. 1Open the completed case. If its outcome is missing, the note “Outcome missing” sits at the very top.
2. 2Click “Record outcome” in the note.
3. 3Pick the outcome from the template’s list and add a reason if needed — say, why a quote was lost.
4. 4The note disappears; the outcome sits on the case and in the case list, and the change can be traced in the activity feed.
5. 5If the template says this outcome is followed by a next step, Bricksta creates the follow-up case right away; both cases point at each other.

How a case ended

Some cases do not simply end — they end well or badly. A quote is won or lost, an application approved or rejected. If the template defines such outcomes, you record which one applies when the case completes. The status says that the case is over; the outcome says how it went — both sit side by side, neither replaces the other.

A case usually completes on its own as soon as its last task is done. At that moment nobody is there to choose — so Bricksta does not stop it from completing but notes “Outcome missing”. A recorded outcome can be corrected; a slip does not have to stand.

Often the outcome is already part of the flow: if a request branches into “Accept” and “Decline”, the branch that runs to its end also settles the outcome. An answer can decide the outcome in the same way.

End on answer

If a case ends through an answer (“End on answer” in the template), you see it beforehand: when you pick the answer that ends it, the line “On “No” the case ends with “Decided not to take part” as soon as you complete the task.” appears right below the field, and the button reads “Complete and end case”.

Only completing ends it; open tasks are dropped and the case carries the outcome. Anyone who then tries to complete a dropped task is told that it has been dropped in the meantime.

The follow-up case

Some outcomes trigger the next step: if the template says that “Won” is followed by order processing, Bricksta creates a follow-up case on its own the moment the outcome is recorded — from the template chosen there, with the fields the template lets carry over (sponsor, congress, amount), started like a case created by hand. Only what you may see yourself is carried over.

If the target template sets a pattern under “Title of new cases”, such as “{{sponsor}} — {{congress}}”, the follow-up case takes its title from the carried-over values; fields only certain roles may see stay out of it. You don't have to type the pattern by hand: under “Insert field” exactly these fields appear in the group “Carried over from the previous case”.

Both cases point at each other: the request shows “Follow-up #1520” at the top, the processing case “from #1118 · Won”. In the case list each carries a small chip in its row, and both are clickable.

The chip with the money status

In the case list, the “→ Follow-up #1520” chip on the request also shows where the money stands. Pledged is the amount in the first sum column of the request template’s overview. Received is the amount in the field chosen as “Amount received” for the follow-up.

Request and child cases

If you send a sponsor several offers at once, you record them in one request as cards and send them together. When the task the template names for this (say “Send offer”) is completed, Bricksta creates one child case per card — with its own history, its own outcome and its own follow-up case. If the request creates an offer PDF per card, each child holds a copy of its card’s PDF.

The request keeps running and shows a “Child cases” section at the top: per child its number and title (clickable), what it is waiting on or its status, the outcome, the amount, the child’s due date and who is responsible for it. You set the due date in the child’s template (say “due on” from a date field); if the template has none, the follow-up date shows instead — the earliest due date of an open task.

The header says how many children there are and how many are still open (open means: not finished and without an outcome), plus the total of the amounts. You only see children you are allowed to see, and the total only covers those; if a child’s amount is reserved for certain roles, it is left out, and there is no total rather than a partial one.

Each child shows “belongs to #12 · Sponsoring request” at the top, linking to the request; if you may not see the request, it only says “belongs to a request”. A child case is not a follow-up case: the follow-up comes from an outcome, the child from a card.

How the request and its children count in the stacks of the case list and in “Action needed” is explained in “Totals, stacking and target tracking”.

Shared file and date fields

A file or date field of the child case can be the same field as in the request — say the signed contract or “Contract received on”. Then the value exists only once, sits in the request and applies to all of its child cases. You set this up in the child case’s template on the field, under “Value from the parent case”.

Cases for the same entry

If several cases refer to the same dataset entry in their header — say the congress “ASCO 2027” and every order for “ASCO 2027” —, the template can show a list of those cases, for example “Sponsors” in the congress case.

Each such list is a view of its own at the top right, after “List”, “Diagram” and “Analytics”: a tab with its name and the number of all cases in it you are allowed to see, say “Sponsors 12” — the number stays the same whichever filter is chosen inside. If the template has no list, there is no such tab.

The view shows the list name, the entry, the count, and below it per case its number (clickable), title, status or outcome and the configured columns, such as sponsor and contact. If a case has no title of its own, it reads “Untitled” with the name of its template; an empty column shows “—”, so you can see what is still missing.

“All”, “Open” and “Closed” filter; the template sets which one the list starts with. When someone changes one of those cases, the list updates by itself. Only cases you are allowed to see appear — the count only covers those too —, and only columns you are allowed to see; the list says so underneath.

The template can also set a reminder: if an order refers to an entry that has no congress case yet, the configured role (say “Congress lead”) gets the task “Kongress ASCO 2027 anlegen” in that order — once per entry, even when several sponsors commit, and not if the congress case already exists.

You set this up in the template under “Settings” → “Who sees what” → “Cases for the same entry”: “Add list”, then the name (say “Sponsors”), which templates are listed, the dataset field in the header whose entry they refer to, up to eight columns from their fields, what the list starts with (All, Open, Closed), how many cases it shows at most and, under “Remind”, optionally the role and task.

You set the task title like the “Title of new cases”: “Insert field” puts values of the order into it, say “Congress [Congress] to create”. Below it you can optionally set the task description, also with “Insert field”; if you leave it empty, the task has no description. Anyone who manages templates can change it; it takes effect at once, without publishing, and a copy of the template keeps the lists.

Payments and credit

If an invoice has been issued on a card, the case shows a “Payments” box at the top: invoice amount, paid, outstanding, the status (outstanding, part-paid, paid, overdue, cancelled) and when the invoice is due. The due date comes from the payment term: the customer dataset holds it as the billing detail “Payment term” (days); it can be changed on the order.

Credit arises when a payment is not allocated to an invoice: whatever is not allocated becomes the customer’s credit with that company. If the customer has credit, their outstanding invoices show a note “Credit of … with …” with “Allocate”; Bricksta uses the oldest payment first.

All credit is listed on the “Credit” page. It is read only and appears in the menu only with the “Maintain billing details” permission. Each row leads to the customer’s outstanding invoice that is due first, where you settle the credit with “Allocate”. A customer with credit can only be merged once the credit has been allocated.

If an invoice is paid and its step has “Completes itself once the invoice is paid” switched on (say “Check payment received”), that step completes itself.

Cancelling and reopening a case

If a case is no longer needed, cancel it instead of deleting it. Cancelling and reopening requires the “Cancel case” permission — initially every role that may close cases. Both are recorded in the history.