Some businesses don’t just sell to a customer once — they look after something for them, over and over. A thing that has to be set up, kept in order, renewed before it runs out, and evidenced with paperwork. Records are where that work lives.
You decide what a record is
Finocket ships no list of record kinds, on purpose. You create the kinds your business actually handles, and for each one you say:
- What has to be captured — the details, using the same field types as everywhere else in Finocket: text, numbers, dates, tick boxes, dropdowns, and auto-numbers that hand out the next number for you.
- What paperwork it needs — each kind of attachment, whether it’s mandatory, and whether the copy you hold carries its own end date.
- The rules it has to satisfy — see below.
Two kinds can each have a field with the same name without clashing, so you never have to invent awkward prefixes to keep them apart.
Raising and tracking one
A record is raised against a customer, or against the company they belong to, or both. It carries your own reference, an optional start-and-end date pair, and moves through five plain states: draft, in progress, active, expired and closed.
Open any record and it shows how far along it is — how many of the required details are filled in, how many of the required attachments are on file, and one percentage covering both. Anything with an end date approaching is flagged before it arrives, and again once it has passed.
Open RecordsEverything you track per customer, with its progressRules
There are four kinds of rule, and you can use as many as you like:
- If this, then that — when one field reads a particular value, another field becomes necessary. This is the one you can’t express on a single field on its own.
- All details filled — every field you marked as needed actually has something in it.
- All paperwork in — every mandatory attachment is present, and none of them has run out.
- End date — the record’s own end date hasn’t passed, with a heads-up a set number of days before.
Each rule is either a problem, which stops the record counting as in order, or a note, which is worth seeing but doesn’t block anything. A date that hasn’t arrived yet is always a note, never a problem — nothing that is still fine is reported as a failure.
The document library
Every file you hold for a customer lives in one private library. You can add to it from the record itself — attach a file against the thing the record asks for, and that line stops showing as outstanding — or from the library screen, for anything you keep for a customer that doesn’t belong to one particular record.
You say what each file is, in your own words. Nothing is pre-loaded. Where Finocket happens to have an automatic reader for that sort of document you can point the kind at it, and where it doesn’t — which is most of the time — the file is an ordinary attachment and works exactly the same.
Deleting a file deletes it: the stored copy goes along with the entry, and any record that was counting on it goes straight back to needing one. That is also what happens when a customer asks you to erase what you hold about them — the erasure reaches the stored files, not just the list of them.
Open DocumentsEverything you hold for your customers, kept privateBefore something runs out
Anything with an end date — a record, or a file you hold against one — is announced before it arrives. Each kind of record says how much notice it wants; thirty days to begin with, and you can change it per kind, because something you redo every quarter and something you redo every five years don’t want the same warning.
What happens then is up to you, and it uses the same automation as the rest of Finocket: the approaching date is an event your rules can react to. Send yourself a notification, email the customer, call a webhook, or open the next one as a draft. Anything that goes out still passes the same consent and quiet-hours checks as every other message Finocket sends, so a customer who has opted out is never messaged because a date came round.
You are told once per cycle, not once a day. When the date moves, the next cycle gets its own notice.
Opening the next one drafts a record against the same customer, starting the day after the current one ends, carrying the same details forward — except any number Finocket hands out for you, which the new one gets fresh. It is a draft, and it tells nobody. Ask twice and you still get one draft.
Through the API
GET /v1/records lists what you track, filtered by kind, customer or state; add include_types=1 and the same call also returns the kinds you’ve configured, so an integration can discover them rather than guess. POST /v1/records raises one, identified either by the kind’s id or by the short name you gave it. Details sent along are checked against that kind’s own setup, and anything that doesn’t fit comes back field by field.
The library has its own calls. GET /v1/record-files lists what you hold, filtered by record, customer or how soon it runs out; POST /v1/record-files uploads one; GET /v1/record-files/{id} returns the details plus a short-lived link to the file, because the store itself is private; and DELETE /v1/record-files/{id} erases both the entry and the stored copy. All four use the same read and write permissions as records.