Changelog

Automations that do more, files on tickets, and dashboards from your own data

What you asked for once you used 1.3. Two of these reached you earlier the same day, as soon as they were ready; the rest arrive together with this release.

• A workflow that doesn’t run says why, and its runs have a page of their own.
• Your bookings, the spaces you look after, ticket targets and asset service on the calendar.
• Workflows start when a vendor or a system is added, a purchase request is submitted, or a date is coming up, and can assign a ticket, move it on, add a note or put an event on the calendar.
• Files on tickets, attached while you write the reply.
• Dashboards on your Service Desk tickets and your vendors, each person counting only what they can open.
• An asset’s history and a lesson’s versions have pages of their own.

Calendar, Spaces & Bookings, Service Desk, Dashboards and Automations

Unlike earlier releases, everything in 1.3.0 arrived together, on this date: two things every plan gets, three new apps, and a way to join one app to another.

• A calendar on every plan: company events for chosen people, beside the dates your apps already keep, and a feed for Google Calendar or Outlook.
• Files & Storage on every plan: what your storage holds, where, and freeing it.
• Spaces & Bookings: rooms, desks and pods booked by the hour, never twice, with check-in, approvals and a screen outside each room.
• Service Desk: IT, Facilities and HR requests in queues, with numbered tickets, internal notes, fair targets and ratings, and broken equipment reported as a ticket.
• Dashboards: the CSV a team already keeps, as numbers and charts shared as totals.
• Automations: when something happens in one app, do something in another, with each plan’s runs a month.
• Scale now includes every app. A change to your subscription keeps the prices you already pay.

A field you are typing in no longer looks bigger than the fields beside it

The field with the cursor drew a heavy ring outside its border, so it looked larger than the fields in its row, and a dropdown you clicked showed a different, fainter one. Every field and dropdown now shows the same teal border and soft ring when it has focus, inside the same box. Buttons and links keep their keyboard ring.

Weekly KPI reminders stop after ten

• An overdue KPI result is reminded weekly up to ten times, the last saying so, like every other weekly reminder. The KPI stays waiting for an update on its scorecard.
• The audit history lines an offboarding writes about returned equipment and removed access no longer name the leaver. Each line's detail says whose it was, and reads Deleted user once they are erased.

Access reviews you sign

An access review used to mean editing two dates. Now it is a decision about each person, signed and kept.

• Review on a system lists everyone with access and since when. Keep or remove each person, set the next review and sign. Nobody can be left undecided, and a list that changed while you were reviewing is refused and reopened on the current one.
• Removals take effect as you sign, each recorded in Audit history, and the system's last review becomes the day you signed.
• Each system's history shows its signed reviews with every decision, and every grant and removal of access. Export reviews gives every review as CSV.
• A signed review cannot be edited or deleted, and keeps pointing at anyone later erased.
• An overdue review is reminded weekly, up to ten times, until one is signed.

Access you can trace

Changing who could reach a system left one line in the audit history saying the system was updated. Now each change says whose access it was.

• Every grant and every removal of system access is its own entry in Audit history, naming the person and who made the change, whether it was made on the system, by an offboarding or by an erasure.
• Each person on a system shows when their access was granted.
• An administrator who manages only some locations keeps, rather than silently removes, the access of people at other locations when they save a company-wide system. Saving from a view filtered to one location used to drop everyone the filter hid.
• Moving a system's next access review is recorded with the old and the new date.

Equipment shows when it is due back, and is chased until it is

A return date could be set when equipment was checked out, and nothing showed it or followed it up. Now it is on the register, in the Employee Portal and in the reminders.

• A Due back column and an Overdue filter on the asset register, and the date on each custody period.
• The person holding it sees the date in the Employee Portal, and is reminded the day before and on the day. Once it is late, they and the people who manage assets at that location are reminded each week, up to ten times.
• The date can be changed without reissuing the equipment, and checkout refuses a return date that has already passed.
• Reminders follow the apps a workspace has installed: removing an app stops its reminders, which used to link to pages that refused the people they were sent to.
• GET /api/v1/assets?status=ASSIGNED lists checked-out equipment, where it used to refuse the value.

Approvers are emailed, and reminded while a request waits

A purchase request told its approver only in the app, so it could wait unseen. Now every step reaches the person it concerns by email as well, with a link to the request itself.

• An approver is emailed when a request reaches them, comes back revised, or is withdrawn, and the requester is emailed each decision.
• A request still waiting three days later reminds its approver, then once a week, up to ten times. Requests already waiting are reminded on the first sweep after this update.
• A stage with no named approver now tells everyone who can sign it, where it used to tell nobody. A withdrawal tells whoever the request was waiting on, and a second request for changes reaches the requester.
• A new Approvals switch on your profile turns these emails off without turning off reminders. It starts on for everyone.
• Imports still send nothing when they run.

KPI Scorecards, the apps you choose, and registers you can work in bulk

1.2.0 names the updates below as one release. Each reached kitset.io on the date it shows; this is the version number they share.

• KPI Scorecards is the ninth app, and a workspace chooses which apps it pays for.
• Imports you review before anything changes, and exports that run in the background, through Jobs.
• Saved views, chosen columns and bulk changes on Vendors, Assets and Systems, and bulk changes to tasks.
• A Developer API sync that misses nothing, the API’s first write, and every webhook event sent when it says.
• Repairs to checkout, trial subscriptions and subscription changes, and limits on email and guessing.
• A page for each app, and every price on this site generated from the price list.

Subscription changes reach Stripe again, and every app has a page

Adding or removing an app on a paid subscription answered with an error instead of making the change. That is fixed, and the public site has a page for each app.

• Update my subscription on the billing page, and Change apps in the app catalogue, reach Stripe again. Stripe refused the way each line of the change named its product, so nothing was changed and nothing was charged.
• Each app has a page of its own, listed at /apps: what it does, how it works, what it costs and which apps it works with. Starting a trial from one ticks that app.
• Every single-line form control is the same height, and a field no longer stretches beside a neighbour that has a note under it.
• Every price on this site comes from the price list. One answer on /pricing had KPI Scorecards’ price typed in. It was right, but the check the 0.9.0 entry describes only confirmed that each right figure appeared somewhere on the page. It now fails the build on any typed price.

Every webhook event now fires when it says it does

Four of the eight events an endpoint could subscribe to were never sent, and a fifth was sent at the wrong moment. If you subscribed to any of them, they start arriving now.

• purchase_request.decided, when a request is finally approved or rejected.
• transition.started, when an onboarding or offboarding is submitted, and transition.completed, when it is marked complete. The second used to be sent when the transition was acknowledged.
• learning.acknowledged, when an assignment is completed.
• vendor.renewal_approaching, once per renewal, when the cancellation deadline comes within 30 days.
• Each API scope now describes exactly what it returns. Two promised custody history and access lists the API has never returned.

When each event is sent is listed on /developers/webhooks, generated from the code that sends it.

KPI Scorecards, the ninth app, and choosing the apps you pay for

KPI Scorecards replaces the spreadsheet a team keeps its numbers in. It is an app like the other eight: one of the apps your plan includes, or an extra at its own price.

• Each KPI has a target, a cadence and a person who records it. Results are recorded once a period closes, a correction keeps the target the period was judged against, and whoever records a KPI is reminded when its result is due.
• The scorecard shows what is on target, what needs attention and what is still waiting. Each KPI has a page with its trend, every result and a change log, and the console overview and the Employee Portal show the updates that are due.
• Five built-in templates beside your own. Archive, restore, reassign or move up to 100 KPIs at once. Import from CSV with a preview, and export, as a background job for Console users.
• The Developer API reads KPIs and their results, and has its first write: recording a KPI result for a closed period, under a scope that can do nothing else.
• The owner chooses the workspace’s apps on the billing page, and anyone who can manage billing can use Change apps in the app catalogue, with a live estimate. A plan includes your most expensive apps, and each app past that is billed at its own price. On a paid subscription the change goes to Stripe, prorated, and the apps change once Stripe confirms it.
• A subscription in its trial is still a subscription. The billing page offered checkout again to a workspace that had subscribed during its trial, and a second checkout would have started a second subscription, billed when the trial ended. Choosing a plan on a subscribed workspace no longer changes it without a payment.
• A dialog belongs to the page it was opened on. Going Back or following a link with one open used to leave it over the next page, and saving it there could draw the wrong page.

Exports the terms promise, and an API sync that misses nothing

• Handovers and Employee Transitions have Export CSV. The terms promise that every register can be exported, and these two could not be.
• The purchase export includes each purchase’s cadence, so a recurring purchase exported and imported back stays recurring instead of becoming a one-off.
• A sync using updated_since sees every change. A change made beneath the product, such as a data correction, or a link cleared when the record it pointed at was deleted, did not move updated_at, so an integration never saw it.
• An edit that would make a reporting line or a department tree loop back on itself is refused, however long the loop. The People import always refused them; a single edit caught only the shortest.
• Continue to checkout answered an error instead of opening Stripe’s checkout. Fixed on 3 October.

Imports you review, exports in the background, and registers you can arrange

Bringing a register in from a spreadsheet, and taking it back out, is no longer one request that has to finish while you wait.

• A Jobs page runs CSV imports and exports in the background, with progress, cancel, retry and download. Your jobs are private to you; owners and admins can see the workspace’s.
• Imports for Vendors, Assets, Systems, Workplace, Purchases and People are virus-scanned, then shown to you for review before anything changes. An imported purchase request goes through the same approval stages as one made by hand.
• An asset import updates the asset its tag already names. A People import updates people already here, matched by email: name, job title, department, team, manager and cost centre, never their access.
• Exports for Vendors, Assets, Systems, Workplace and Purchases run as jobs, in the order the register showed.
• Vendors, Assets and Systems keep saved views, personal or shared with the workspace, open with a default view, and can be sorted and shown with the columns you choose.
• Bulk changes on those three registers: up to 100 selected records, or every record matching your filters up to 1,000, all or none. On Tasks, reassign up to 100 tasks or change their due dates at once.
• Limits on the email a workspace can make kitset.io send, and on guessing. Ten wrong second-factor codes in an hour pause that account’s codes and email its holder, at most once a day, and a sign-in ended that way says why. Reminder emails no longer go to people who never accepted their invitation.
• Sign-in session records are deleted 30 days after a session ends, as the privacy notice says; production was not running that cleanup. Uploads are scanned with virus signatures kept current while the scanner runs, not as old as the last deploy.

Tasks you write, and courses taken one step at a time

• Console users can write tasks and assign them to colleagues, and a Portal user can keep a to-do list of their own. Tasks come with every plan.
• A course is a sequence of text, images, video and questions in any order, written and taken one step at a time on a page of its own. A learner reaches each question only after what comes before it, and picks up where they left off.
• Fixes to things you could see: search boxes that did not search everything they offered, counts that described one page while claiming the whole workspace, exports that could leave out different rows each time, Developer API filters that were documented and not applied, and a calendar that closed itself whenever you tried to move through it.

A Developer API you can integrate against

Everything in kitset.io was reachable only through this browser client. If you wanted your asset register in your CMDB or your leaver events in your service desk, the honest answer was a CSV export and a cron job.

• A documented, read-only API over eleven registers — assets, vendors, systems, people, purchase requests, locations, tasks, handovers, transitions, learning assignments and workplace records — with cursor paging and an updated_since filter so a nightly sync moves what changed rather than everything.
• Workspace API keys, scoped to the registers an integration actually needs. A key belongs to the workspace rather than to a person, so it keeps working after whoever created it has left. It is shown once, expires, and can be revoked immediately.
• Signed webhooks, so your systems hear about a checkout, an approval or a leaver when it happens instead of polling for it. Every delivery is signed, retried on failure, and recorded in a log you can read.
• Documentation at /developers, with the endpoint reference generated from the API itself so it cannot describe something that is not there.

Off by default. A workspace sees no change until an owner creates a key.

The money path, erasure, and two registers that stopped lying

The release a first paying customer can be sold. Every headline below was something the product either could not do or described incorrectly.

• A paying customer can change plan, modules and capacity from the billing page. Before this, selecting a plan answered 409 once a subscription existed, and a change made inside Stripe’s own portal moved money and granted nothing.
• Signup no longer grants an allowance the chosen plan does not sell.
• Purchase requests route to the requester’s manager, and above a threshold to finance as a second stage. The manager relationship existed and no code had read it.
• Employee Transitions is a joiner/leaver flow rather than the Handover table under a second price: an offboarding builds its checklist from what the person actually holds, and completing one returns the equipment and revokes the access.
• A workspace Owner can erase an individual, and an operator can delete a whole workspace. The privacy policy had promised this and nothing implemented it. /privacy §9 says precisely what erasure keeps.
• Who can reach a system, and who has held a piece of equipment, are now records that can be queried. “Who had this laptop in March” was previously unanswerable.
• Two authorization gaps closed: a revoked learner could still complete a compliance course, and the delivery centre refused people its own permission had admitted.

A public front door, real auth URLs, and a platform operator console

Every path served the same application shell, so a crawler executing it got “Preparing your workspace…” and the whole domain indexed as the sign-in form. There was no marketing content, no robots.txt, no sitemap, no favicon and no <h1> in anything served.

• Fourteen server-rendered pages at real URLs, plus a branded 404. Nothing on them quotes a number by hand: the pricing table, plan capacities and module cards are generated from the catalogue, and a test fails the build if a figure is typed in.
• Sign in, start trial and forgot password have their own addresses, and every deep link into the application is built by one function rather than assembled at each call site.
• The application shell moved to /app and is marked noindex; unknown paths return 404 rather than 200.
• A platform operator console, off unless enabled, with its own identity, mandatory two-factor authentication, and a structurally read-only surface. Every read it performs is recorded where the record outlives the workspace it describes.
• The backup and restore drill was written, run for the first time, and failed — on a source database that had never been stamped with a migration version. It refuses that source now, and the reference run restores and boots.

Database parity, delivery feedback and learning integrity

The whole test suite now runs against PostgreSQL as well as SQLite. The first run found a column overflow that had passed every previous test and would have aborted a transaction in production, plus two foreign keys the migrations had never created.

• Bounce and complaint feedback from the mail provider is ingested and enforced, so a hard-bounced address stops receiving mail platform-wide.
• Learning content is genuinely versioned. Acknowledgement evidence is insert-only and names the version acknowledged, so republishing a policy no longer rewrites the record of what people agreed to.
• Completion scores come from a server-graded quiz rather than from a number the browser submitted.
• Global search across every module, with escaped patterns, plus a command palette.
• Structured JSON logging with credential redaction.

Organization, audiences and scoped access

• Managed departments and teams with codes, cost centres, hierarchy and managers.
• Job title, department, team, manager and cost centre on every person.
• Dynamic audiences, so content is assigned to a department or a location rather than to a list that goes stale.
• Scoped permission grants, and CSV import and export for people.

Hardening

• Two-factor authentication, enforced on the session rather than on the sign-in form, so password reset and invitation acceptance cannot walk past it.
• Signed scanner callbacks, webhook replay defence and wider rate limiting.
• Direct-to-storage attachments with quarantine on a metadata mismatch.

Clean architecture and multi-location operations

• Explicit architectural layers, with dependency boundaries validated automatically.
• Managed locations as shared authorization and reporting infrastructure across every module.

Production foundation

Managed PostgreSQL, private object storage and a real transactional mail provider, replacing the single-file development assumptions.

Account lifecycle

Expiring single-use invitations and reset links stored only as digests, session control, notifications and reminders.