Team Interactions in Records
Audience: Administrators, Developers, Solution Architects
Purpose: Explains how user interactions create or update Record associations and how those associations influence visibility and access across the platform.
Overview
Team interactions are user-driven activities that establish or reinforce associations with a Record. They signal participation and influence how visibility is evaluated under My Associated Records scope.
An interaction:
Indicates engagement with a Record
Creates or reinforces an association
Supports collaborative Workflows
Intersects with permission evaluation
However, association and interaction are not identical:
An interaction generates an association
A user can be associated with a Record without having interacted with it
Interactions operate within a layered visibility model that includes:
Ownership
Direct associations
Relationship-based inheritance
Permission Groups
Interactions contribute to association logic but do not override permission configuration.
What Qualifies as an Interaction
An interaction is an action that meaningfully modifies, logs, or contributes to a Record’s timeline history.
Examples include:
Modifying a Record (field updates, stage changes)
Logging an Activity
Adding notes or comments
Starting an automation from the Record (when executed in user context)
Most interactions correspond to entries in the Record Timeline.
Note: Viewing a Record does not create an association. Only user-driven interactions generate associations.
How Associations Are Created
When a user interacts with a Record, the platform may create or update an association between that user and the Record. Associations fall into two categories:
Direct Associations
Created when a user:
Is assigned as the owner
Is added through a team selector or user field
Logs an activity tied to the Record
Modifies the Record
Direct associations:
Are stored on and editable from the Record
Are evaluated during permission checks
Inherited Associations
Derived from relationships with other Records. For example:
An Agent associated with a Client
A Policy related to a Client
A Deal related to an Account
If a user is associated with a parent Record, they may inherit association to related child Records depending on relationship configuration and permission scope.
It's important to note that:
Inherited associations cannot be edited from the child Record
They must be modified at the source (the related parent Record)
Interaction Reinforcement & Role Visibility Within the Association
If a user is already associated with a Record:
Additional interactions reinforce participation history
Duplicate associations are not created
Association alone does not guarantee visibility. Access still depends on:
Object-level permissions
Whether the My Associated Records scope is enabled in the user’s Permission Group
Field-level permissions
Action permissions
Association qualifies a Record for evaluation under My Associated Records. It does not independently grant access.
Timeline Sharing and Relationship Effects
Relationships can extend visibility beyond a single Record. When relationship configurations enable Timeline sharing:
Timeline events from one related Record may appear on another Record when Timeline sharing is enabled
These events may predate the child Record’s creation
Timeline sharing is controlled by relationship configuration. Activity from one related Record may appear on another Record, even if it occurred earlier. This can influence how participation appears in reporting or portal contexts.
For relationship structure and inheritance configuration, see Object Relationships.
Automation and Interaction Context
Automations run in a separate execution context.
Implications:
Automation-triggered updates may create timeline entries, but do not create user associations.
In most cases:
Edit access is required to start an Automation on a Record.
Custom actions can grant limited permission to run specific Automations.
When designing visibility rules based on associations, consider how Automations may create, update, or modify Records in ways that affect who can see them.
For more information, see Automations. (Coming Soon)
Important Considerations
When designing collaboration and access strategies:
Interactions do not override Permission Groups.
A user must have permission to access the Object itself (such as Clients, Deals, or Policies) and must also meet the Record-level scope requirements (All Records or My Associated Records).
Removing a direct association may remove visibility under My Associated Records.
Inherited associations must be modified at their source relationship.
Sharing team associations across related Objects can significantly expand who qualifies for visibility, making access behavior harder to predict.
Shared timeline Activity can affect how past engagement appears.
Architectural clarity prevents unpredictable access behavior across UI, automation, reporting, and API usage.
What’s Next
Understanding Team Interactions ensures that administrators design predictable access strategies, architects model relationships responsibly, and developers anticipate visibility behavior when interacting with Records programmatically.
To understand how interaction and association behavior surfaces in API responses or learn about Records more generally, explore the topics below:
Last updated
Was this helpful?