Type Alias DataAccessConfigType

Role restrictions — role assignment via the legacy role_list column on sys_agent_access_role_configuration. Roles resolve to sys_ids at build time and are stored as a comma-joined sys_id list.

Accepts:

• Role sys_id strings (GUIDs) — pushed directly into role_list.
• Role objects — Role({ $id, name, ... }). The role's build-time sys_id is resolved by the SDK keys registry and stored.
• Record<'sys_user_role'> references — resolved to the referenced record's sys_id at build time.

Not accepted: plain string role names (e.g., 'admin', 'itil'). Use roleMap for name-based authoring — that path resolves names to sys_ids on the target instance at install time, which is cross-instance safe. roleList only stores literal sys_ids and is intended for:

• Backward compatibility with pre-ZP10 / pre-AP3 customer instances (which lack the sys_agent_access_role_mapping M2M table).
• Cases where customer instances are cloned from a common production baseline so role sys_ids match across all targets.

Either roleList or roleMap (or both) must contain at least one role — the build fails with a diagnostic otherwise.

Name-based role assignment via sys_agent_access_role_mapping (M2M).

Accepts:

• Role name strings for OOB or platform roles (e.g., 'admin', 'itil').
• Role objects for custom roles defined by this app via Role({ name, ... }).
• Record<'sys_user_role'> references via Record({ table: 'sys_user_role', data: { name } }).

Each entry is emitted as a platform-resolvable reference — the target instance's coalesce logic resolves the role's name to the correct sys_id. This makes roleMap cross-instance safe even when role sys_ids differ across instances. Requires ZP10 / AP3+.

Note: Record<'sys_user_role'> cannot carry sys_id-only data (TypeScript rejects data: { sys_id: ... } because sys_id is not in Data<'sys_user_role'>). Users must provide name (or another coalesce key column) in data.

Sys_id-based references go to roleList instead. At least one of roleList or roleMap must contain a role.