Permissions
Access to items follows two layers: the team role of the user, and the Help Desk Agent visibility of each item type.Team roles
Every team role grants a specific level of access to item data:
See Team roles and permissions for the full matrix across all platform resources.
Help Desk Agent visibility
Team-role access doesn’t automatically grant access to the Help Desk Agent. Each item type has its own visibility setting that decides what the agent can read at runtime:
Set None for sensitive types (compensation, security audit logs) that should never reach the agent, even if a Builder has otherwise granted broad access. Set Always for catalog and reference data the agent might need across requests.
Table and field access
A table or field can narrow the audience it gets from the database above it, but never widen it. Open a table’s access from the access badge in its header (Everyone, Write restricted, or Restricted), or a field’s access from Edit field permissions in the field’s actions menu. When the database is shared with specific teams rather than the entire organization, select Add teams, roles, or people to limit the table or field to a role, group, or person. These rows show Only if they also have access above: they reach the table only if the database already gives them access. For example, to let only the Security Lead role inside Corporate IT see and edit a table:- Open the table’s access.
- Select Add teams, roles, or people and pick the Security Lead role.
- Set the role to Can write.
- Set Corporate IT to No access.
Record-level access rules
Beyond the type-wide audience, a manager can restrict a single record. Open the record and select the lock icon in its header to narrow who can read or write that row below the item type’s audience. People without access see the record as a Restricted record placeholder with a lock instead of its field values, and its detail page explains that a manager of the database can grant access. Filtered lists note when restricted records can’t be included in the results.Editing items from workflows
Workflows run with the permissions of their owning team. A workflow exposed to the Help Desk effectively gives end users access to whatever it touches.History and provenance
When a field value changes, Serval records the change in field value history. Each change creates a new history entry; the prior value is kept as a deleted row. History captures:- What changed. The field, the new value, and (by comparing earlier entries for the same field) the previous value.
- Who changed it. A user (manual edits via UI or API), or an ingestion source (shown as the connected app instance). Workflow runs aren’t recorded on individual field history entries.
- When. Timestamp of the write.
ListEntityFieldValueHistory).
Reading history in the UI
Open any item and click Field History in the side panel. Each row is one change to one field. Filter by field to trace a single value’s lineage, or by author to see what a workflow has been writing.Reading history from workflows
You can build workflows to read field history programmatically. The common use cases:- Alert on field change. A scheduled workflow reads recent history for an item and notifies users when it changes.
- Debug a stale value. Walk back through history to see which source last wrote the field and when. Useful when a sync isn’t refreshing what you expected.
- Provenance reports. List every value on a sensitive field along with its source, for compliance audits.
Provenance and source of truth
Each value carries the identity of whoever wrote it. For fields with multiple ingestion mappings, history shows which source won at each write. This is the audit-grade answer to “where did this number come from?” for finance and compliance teams.Archiving and deletion
Removing an item has two lifecycles: archive (reversible) and delete (permanent). Archive hides an item from the default list and per-type counts while keeping it intact: it stays loadable by ID or key, still resolves when referenced, and keeps its key reserved. Use the Show archived toggle on the list to see archived items and Unarchive to restore one. In references, an archived item shows muted and labeled (archived); a deleted item shows struck through and labeled (deleted). Delete removes an item permanently: there’s no restore, and its key is freed for reuse (change history is still retained for audit). Prefer archive when you might need the item back. If the item is fed by an ingestion config, disable the source mapping or change the source data, or the next sync recreates it.Delete items in bulk
To remove every item matching a filter, use a workflow that searches and deletes. The list view doesn’t expose bulk delete by default, to avoid accidents.Delete missing items vs. manual deletions
The Delete missing items toggle on an ingestion config controls whether deletions at the source cause Serval to delete the corresponding item. Hand-deleting an item is independent of this: it removes the item from Serval, regardless of whether the source still has it. See Ingestion.Delete an item type
Deleting an item type also deletes all of its child types. The items themselves aren’t permanently removed. Instead, they stay hidden from queries, but are kept for audit. You can’t recover a deleted item type through the API. Before deleting an item type, check for:- Any workflow that reads or writes it. The workflow will fail on its next run.
- Any skill that references it. The agent will fail to resolve the reference.
- Any custom ticket field or catalog item that uses it as the reference target.
- Any other item type with reference fields pointing at it.