We have introduced notes — free text you can attach to your data, stored together with the author, the time and where the note was written. A note cannot be edited or deleted once written.

We are launching notes for users first, which covers your drivers, organization managers, customers and admins. In practice that means:

• The dispatcher who called a driver after a missed pickup writes down what was agreed. Whoever handles that driver next reads it on the driver’s profile instead of asking around.
• The admin who blocks a driver notes why. Whoever decides later whether to unblock them reads that on the driver’s profile instead of guessing.
• A note can be addressed to the driver themselves, so a request for missing paperwork reaches them through your own integration instead of a separate channel.

Until now that context had to go into a metadata field anyone can overwrite, a spreadsheet, or a chat thread that isn’t connected to the driver at all.

• List notes reads the notes on one user, newest first, up to 30 per page, with each note’s author included so you can render a list with bylines from one request.
• Create a note writes a note.

Every note names its audience

When you write a note you list the roles that may read it. A note on a driver can stay between admins, include the managers of that driver’s organization, or include the driver — and notes with different audiences sit side by side on the same driver. Customers are an audience just as much as your staff: a note on a customer’s own profile that includes their role is something they can read through your integration. Your own role is always part of the list, so you cannot write a note you would not be able to read back.

Notes also inherit the access rules of whatever they are attached to: if a user is not visible to you, neither are their notes.

The origin of a note is recorded, not claimed

Each note stores whether it was written from the dashboard, from the driver app or through the API. We take that from the request itself rather than from the payload, so nobody can post a note that claims to come from somewhere else. A fourth value, system, marks the notes we take automatically as part of platform operations — blocking a user, for example — rather than notes a person wrote.

Notes written through the API also keep the name of the API token that created them, so you can still tell which integration wrote a note after that token has been deleted.

A paper trail for automated steps, ours and yours

Over time we intend to use notes more widely as a place where our own built-in functionality can leave an explanation behind. Notes like that carry the system source and sit on whatever they concern, alongside the notes your team wrote by hand.

Your integrations can and should be used the same way. When an automated process of yours acts on a user — pausing a driver after a failed document check, say — have it write a note stating what it did and on what grounds.

Format and limits

A note’s message is up to 500 characters and supports a limited set of Markdown features: bold, italic, inline code, code blocks, bulleted lists and http(s) links. Anything else — headings, images, tables, raw HTML — comes back as plain text, and links that are not http(s) are not clickable.

The message is handed back as HTML that is ready to display, so there is nothing left to escape on your side.

The Notes overview documents the whole surface, including the visibility rules and the supported Markdown.

What comes next

Notes launch for users. We plan to roll out support for bookings, tours, packages and other data types in the future. The type is part of the path, so an integration you write today can pick those up without changing shape.

Notes on bookings are what will make this useful for customer communication: a note that includes the customer as its audience is a plain way to keep them posted about their booking, written by hand or by an automated process of yours. Because the mechanism itself is so simple, it bends to whatever a given operation needs to communicate, instead of asking for a purpose-built feature per case.

Support in our own apps is planned as well. In the web dashboard, your team will read and write notes on a user directly, choosing each note’s audience as they write it, with no integration of your own involved. In the driver app, drivers will see the notes that were shared with their role — so a note addressed to a driver reaches them there instead of through a channel you have to build yourself.