Support/Getting Started/Record visibility: Personal, DataRoles and Locations

Getting Started

Record visibility: Personal, DataRoles and Locations

Choose an explicit scope when creating records, understand inherited child visibility, and safely update shared records.

Open raw .md
Applies to
User-managed business records
Choose on
Top-level create or scope move
Authority
Verified user and current permissions

Create a Personal record

Select Personal in the record’s visibility choices. The record belongs to you, has no location and gives its owner control. Another user’s membership in your organization does not make your Personal record shared.

Create a shared record

  1. Select one DataRole in which you are allowed to create this kind of record. App navigation and your User Type do not choose a DataRole for you.
  2. When active Locations exist, select one authorized location. Select All only if you have all-location access. An empty selection is not All, even if there is only one choice.
  3. Save the record. The server checks your current authority and commits the record and its selected scope together.

When there are no active Locations, the location field is optional. If no eligible scope choices are available, ask your administrator for the relevant permission rather than attempting to bypass the form.

Add a child record

Create the child from its authorized parent. The child inherits that parent’s DataRole and location within the create operation. Do not select a different scope to make a child visible outside its parent.

Edit or move an existing record

Review the displayed current scope. You do not need to reselect scope for an ordinary edit; explicitly choose the destination when moving a record. The destination still requires current permission. Once shared, a record cannot be changed to Personal. If you need a Personal replacement, create it explicitly and remove the shared record only when you have permission and have considered its history and relationships.

What a page or integration can access

Menus and published pages select presentation. Record reads, edits, removals, files, exports, search and AI each enforce the current user’s relevant permissions. The same contract applies to Developer API, MCP and automation access. A URL, record ID, app ID or organization ID identifies a target; it does not grant authority.

If saving fails

For missing scope, choose an eligible explicit value. For permission denied, refresh your available choices or contact an administrator. For a stale-write conflict, reload the current record and review the other changes before saving again. Keep your unsaved text if possible; do not repeatedly submit a consequential action. Share the safe error code and correlation reference with support.

Capability review: 2026-10-22. See current features and setup requirements, the generated API Map and first-class module inventory.