Some businesses do more than 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.
Setting up a kind
Open Records and choose Record types, then New record type. Give it a name; Finocket suggests a short name from it, which rules and the API use to refer to the kind. The short name is fixed once you create the kind, so you can rename the kind later without breaking anything that points at it. You can also say how many days before an end date you want to be told.
Once it is created, the same panel stays open with three sections:
- Details it captures: add a field with its name and kind: text, long text, number, date, tick box or a dropdown with your own choices. Switch on Needed for the ones that must be filled in.
- Paperwork it needs: add each piece of paperwork in your own words, say whether it is mandatory, and whether the copy you hold has its own end date.
- Rules it must satisfy: pick a kind of rule (described below), give it a name, and say whether failing it is a problem or a note. An If this, then that rule needs at least two fields first, because it names one field and the field it makes necessary.
Removing a field, a piece of paperwork or a rule takes it off the kind without erasing what was already recorded against it, and adding it back under the same short name restores it. A kind you no longer use can be archived; archived kinds stay on the list but are not offered when you raise a new record. Only people with write access to the workspace can change any of this.
Open Record typesDefine what you track, what it needs and its rulesRaising and tracking one
On Records, choose Raise record, pick the kind and the customer, and fill in anything you already know: a title, your own reference, start and end dates, and the kind’s own details. It is created as a draft and opens straight away, so you can attach the paperwork from the record itself.
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 progressImporting a list of records
If you already keep a list of the things you look after in a spreadsheet, the Import records card on Records turns it into records, one row each, tied to the right customer. It takes three steps, and nothing is final until the last one:
- Check file. Choose the Record type and a CSV file. You see every row with its customer, new or already on file, and anything wrong with it. Nothing is saved yet.
- Import as drafts. The button names the count, such as Import 12 records as drafts. It saves the rows as draft records, and adds the customers the check said were new. Rows with errors are skipped, and rows already imported are not added twice.
- Confirm. The button reads, for example, Confirm 12 drafts, and makes them active. Until you confirm, they are ordinary drafts you can open and fix.
When a setup on your workspace knows the column names another program exports, those columns are matched for you. With no kind set up yet, the card says There is no record type to import into yet. Add one under Record types first. Someone whose role can only read sees why they cannot import.
Kinds a setup adds for you
You can still create every kind yourself. A ready-made setup for your trade may also bring a kind with it. When it does, the owner's Apply this setup? screen lists it under Record types that will be added, and nothing is added until the owner taps Apply setup. The new kind then sits under Records like one you made.
Undo removes such a kind only while it holds no records. Once you have raised records of that kind, undo is refused and says so, and your records and details stay exactly as they were.
Rules
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, so 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.