Control Custom Record Audiences

Purpose

Record permissions and property exposure let an organization limit access to sensitive custom information. Each decision has a separate record or field boundary.

How It Works

Security assignments grant shared record permissions with optional object scope. A custom object can additionally require object-specific roles. The service checks reach before returning its records. The console uses permission information to choose available actions and navigation. Field projection narrows readable properties for the audience. Portal ownership predicates are implemented in the data layer. Portal and public routes remain deferred, so those projections do not establish a delivered portal experience.

Relationships

Security owns role assignments. Object settings select the access mode, field rules select exposure and history checks its separate permission.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Record permissions and property exposure let an organization limit access to sensitive custom information.Portal ownership predicates are implemented in the data layer.
Surfaces: consoleapi
Intent sources: services-platform:docs/proposals/custom-objects/09-decisions.md#D-08, D-09, D-10, D-19services-platform:docs/milestones/PLAT-M5-custom-records.md#D-19, PLAT-M5 D10services-platform:docs/milestones/plans/PLAT-M5-plan.md#PLAT-M5-S08, PLAT-M5-S14

Controls

27 controls apply, from the corpus control catalogue.

TC-AVL-005 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-004 TC-DAT-005 TC-IAM-003 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-005 TC-PI-003 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

Key	Checked at	Scope
`platform.custom-records.read`	api	record
`platform.custom-records.query`	api	record
`platform.custom-records.create`	api	record
`platform.custom-records.update`	api	record
`platform.custom-records.delete`	api	record
`platform.custom-records.publish`	api	record
`platform.custom-records.export`	api	record
`platform.custom-records.history`	api	record

Business Rules

9 rules, 7 to be proved before approval. A rule's product intent is derived from its origin: 9 confirmed by a product decision, the rest inheriting this capability's confirmed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Confirmed	Shared record permissions support assignments scoped to one custom object, hiding other object records behind a not-found response. origin: services-platform:docs/proposals/custom-objects/09-decisions.md#D-09 (approved 2026-10-18) proved by `ATS-PFM-MTD-011-01`, `TST-PFM-MTD-051`	permission	api, service	test services-platform:modules/custom-objects/tests/e2e/custom-object-records.e2e.spec.js#refuses the same role another object’s records, answering as if the object were not there
`02`must prove Confirmed	Roles-only objects require an active object-specific assignment in addition to permission reach; built-in, workspace-wide and customer-wide grants alone do not expose them. origin: services-platform:docs/milestones/PLAT-M5-custom-records.md#PLAT-M5 D10 (Andrew, 2026-10-19: "Build it in PLAT-M5") proved by `ATS-PFM-MTD-010-07`, `ATS-PFM-MTD-011-02`, `ATS-PFM-MTD-011-08`, `TST-PFM-MTD-014`, `TST-PFM-MTD-051`	permission	service	test services-platform:modules/custom-objects/tests/e2e/custom-object-records.e2e.spec.js#keeps a roles-only object from a customer-wide assignment, answering as if it were not there
`03`must prove Confirmed	Platform Administrator receives every definition and record key, User receives definition reads plus record read, query, create, update and history, and Read Only receives definition reads plus record read, query and history. origin: services-platform:docs/proposals/custom-objects/09-decisions.md#D-09 proved by `ATS-PFM-MTD-011-03`, `TST-PFM-MTD-072`	permission	api	test services-platform:modules/custom-objects/tests/unit/custom-object-permission-keys.spec.ts#gives Platform User reading, querying, creating and updating records and their history, and reading definitions
`04`must prove Confirmed	Record archival and restoration require the separately granted delete permission and support object-specific scope. origin: services-platform:docs/proposals/custom-objects/09-decisions.md#D-19 (Andrew, 2026-10-18: "Delete key") proved by `ATS-PFM-MTD-011-04`, `ATS-PFM-MTD-011-08`, `TST-PFM-MTD-072`	permission	api	test services-platform:modules/custom-objects/tests/unit/custom-object-permission-keys.spec.ts#requires one key per route, each a console route, the health route public, every record route scoped to its object
`05` Confirmed	Record export is marked sensitive and reserved to administrators, but no current route requires its dedicated key.	permission	api	test services-platform:modules/custom-objects/tests/unit/custom-object-permission-keys.spec.ts#marks exporting records sensitive, and no other key of the two resources
`06`must prove Confirmed	Audience projection shows all properties to staff, owner-or-broader properties to owners, portal-or-public properties to members and only public properties to anonymous readers; portal links exclude staff-only types. origin: services-platform:docs/proposals/custom-objects/09-decisions.md#D-10 (approved 2026-10-18) proved by `ATS-PFM-MTD-006-10`, `ATS-PFM-MTD-011-05`, `TST-PFM-MTD-073`	calculation	service	test services-platform:modules/custom-objects/tests/unit/exposure.spec.ts#shows a portal member the portal and public properties
`07`must prove Confirmed	Data-layer portal predicates combine ownership, organizational roles, links, publication and eligibility, exclude archived records and limit members without contacts to publication or eligibility; portal routes remain absent. origin: services-platform:docs/proposals/custom-objects/09-decisions.md#D-08 (approved 2026-10-18) proved by `ATS-PFM-MTD-011-06`, `TST-PFM-MTD-069`	permission	service	test services-platform:modules/custom-objects/tests/integration/services/persistence/portal-ownership-predicates.integration.spec.js#grants the owner the boat it owns now, and neither an ended ownership nor an archived boat
`08`must prove Confirmed	Console action visibility follows permissions, leaving readers without edit controls and hiding inaccessible object navigation and cards. origin: services-platform:docs/milestones/plans/PLAT-M5-plan.md#PLAT-M5-S08 proved by `ATS-PFM-MTD-011-07`, `TST-PFM-MTD-008`	permission	console	test react-console:acceptance/custom-objects/playwright/journeys/PLAT-M5-S08.spec.ts#PLAT-M5-S08: a read-only volunteer is offered no edit actions; a person without access sees no menu and no card
`09` Confirmed	System execution without a permission slice can reach every custom object in its workspace.	permission	service	documented services-platform:docs/custom-objects.md#18. Records: permissions and scope

Scenarios

Id	Given	When	Then	Provenance
`01`	Enforcement Actions uses object-specific Investigators assignments.	Open the console as an investigator and as unrelated staff.	Investigators can view and edit, while unrelated staff receive no menu, card or record.	test react-console:acceptance/custom-objects/playwright/journeys/PLAT-M5-S14.spec.ts#PLAT-M5-S14: restricted to the Investigators role and granted in Security: only investigators see and edit

Edge Cases

Id	Given	When	Then	Provenance
`02`	Boat access rules include crew and owning-organization billing roles.	Evaluate readers with current ties and an expired organizational role.	The active crew and billing ties grant access while the expired role does not.	test services-platform:modules/custom-objects/tests/integration/services/persistence/portal-ownership-predicates.integration.spec.js#grants nothing through owner_organization to a member whose role there has ended

Planning

Implementation

Control Custom Record Audiences ​

Purpose ​

How It Works ​

Relationships ​