Permissions and the API

Who may do what

To	Permission	Held by
See CIs in your units, with their relationships and history	ci.read	Agent, Viewer, Auditor, Configuration Manager
Add CIs and edit them and their relationships	ci.write, or being its owner (to edit); ci.settings edits too	Configuration Manager
Set a CI's health by hand	ci.status, or being its owner	Configuration Manager
Manage the classes, and import CIs (for the whole organization)	ci.settings for the organization	Configuration Manager
Delete CIs nothing is joined to	ci.settings	Configuration Manager
Relationship kinds	service.settings (Service Configuration)	Service Manager
Environments (shared with services)	ci.settings or service.settings	Configuration Manager, Service Manager
Data properties of CIs, on Design a class	ci.settings or property.settings	Configuration Manager

A permission held in one of the CI's units is enough. Platform Administrators and Organization Administrators hold them all. Give them to your own roles under Roles.

For AI assistants and the API

With the plugin on, tokens can get cmdb:read and cmdb:write (the account menu → API tokens); relationships use Service Configuration's itsm:read and itsm:write. AI assistants get tools to list CIs and read one (also as it was on a date), to see the classes and the options for the forms, to add and change CIs, to set a CI's health by hand, to import CIs from CSV text (checked first unless told otherwise) and list the imports, to export the CIs as they were on a date (kept like any export), and to read and set the CI a case is about, within the same permissions. The incident, problem and change tools take the CIs they name too. The API is described in building a plugin.