Records are the actual entities (people, companies, properties, etc.) or matter data (employment information, trial details, etc.) - that contain the data values your users will utilise in Smarter Drafter forms. Every Record links the previously defined Field Aliases (the data keys) with the actual data values, and is categorised by a Record Type.

API Reference: Managing Records

Use the following endpoint to create new records in Smarter Drafter. Records do not need to always have an associated matter upon initial creation - think of contacts in a PMS that may get created and then added to specific matter(s) later. When adding a record to a matter, it must have a record type defined - think of it as categorising the record in terms of either a role it may be playing in a matter or the type of data it is storing for a matter.

Add a new record

Records already created can be added to a matter using the update endpoint below.

Update the record types associated to a record

Smarter Drafter provides the ability to update the name and ID of a record in your tenant.

Update a record by ID

Field aliases can be updated on a record with the below endpoint.

Update the aliases associate to a record

Additionally records can be deactivated which prevents it from being used in any new matters and being visible when form filling.

Deactivate a record by ID

For more information, see Records full list of APIs.

Set record field aliases to read-only

When you push matter record data into Smarter Drafter via the API, your own system is the source of truth. By default, once that data populates a form, drafters can edit it, which can create a silent mismatch between the value in the generated document and the value in your system of record.

The readOnly property value lets you lock individual field alias values on a record. A read-only value still auto-populates onto forms as normal, but the drafter cannot change it. The property can only be set via the public API - there is no in-app toggle - so enforcement stays with your system.

Setting read-only when creating a record

1. Call Add a new records (POST /v1/clients/Records).
2. In each object in the aliases array, include the optional readOnly property below value. It defaults to false if omitted.

Setting read-only on an existing record

1. Call Update the aliases associate to a record (PATCH /v1/clients/Records/{id}/Aliases).
2. In the addAliases array, update an existing field alias or add a new one with readOnly: true.

​Checking whether a value is read-only

Retrieve the record through any of the Records GET endpoints (Get a record by ID, Get a record by external ID, or Search for records). Each field alias value in the response includes its readOnly state.

COMMON QUESTIONS
Q: What happens if the source value changes after a drafter opens the form?
A: Read-only values refresh to the latest database value. The drafter sees the update on form refresh, or after exiting and re-entering. Once submitted, values are frozen and no longer update.

Q: Can a drafter override a read-only value in the app?
A: No. The field is locked in the form, and the record value's edit button is disabled during record assignment. Hovering over the disabled button shows "Record set to read-only cannot be edited".

Q: Does this affect record values created inside a Smarter Drafter form?
A: No. Values created from within a form default to readOnly: false. Only API calls can set the property to true.

Q: Will this change behaviour for my existing API integration?
A: No. Existing values default to readOnly: false and are unaffected unless you explicitly update them via the API.