CTA Awareness key terms

A shared platform design in which many customer organizations use one application instance while their data and configuration remain logically separated by an Org identifier enforced at the platform layer.

The top-level container that isolates a customer's users, data, and configuration from every other tenant on the shared platform; it defines the security and customization boundary.

An approach where objects, fields, layouts, and logic are stored as declarative configuration rather than hand-written code, so the platform can generate the user interface and database behavior automatically.

The trade-off between configuration tools that are faster to build and easier to maintain and custom code that offers greater control but adds testing, governance, and upgrade burden.

Runtime caps on resource consumption such as queries, CPU time, and callouts that protect the shared platform; exceeding one throws a limit exception and rolls back the transaction.

Designing code and automation to process collections of records in one pass rather than one record at a time, keeping query and CPU consumption inside governor limits during large loads.

Deferring work to background execution such as queueable jobs, batches, or scheduled flows so long-running logic does not block the user's transaction or breach synchronous limits.

The discipline of designing for millions of records: selective queries, skinny tables, indexed fields, and staged migration so performance and limits stay acceptable at scale.

A query whose filters use indexed fields and return a small enough fraction of the table that the platform can execute it efficiently without a full scan.

An administrator-requested database index on a custom field that makes filtered queries and reports selective when the standard indexes on Id, Name, and owner do not cover the filter.

Modeling data as entities with attributes and explicit relationship cardinality before building objects, so that one-to-many and many-to-many needs are represented correctly from the start.

A child object created to resolve a many-to-many relationship, holding a lookup to each of the two parent objects plus any attributes that belong to the pairing itself.

A tightly coupled parent-child relationship where the child cannot exist without the parent, inherits the parent's sharing, and supports roll-up summary fields.

A loosely coupled relationship between objects that allows the child to exist independently, does not inherit sharing, and can be reparented without deleting the child record.

The user or queue assigned as owner of a record; ownership drives sharing inheritance and determines which users see the record under a private or public read/write model.

The baseline sharing setting for each object that defines the most restrictive level of record access, which other mechanisms such as roles and sharing rules can then widen.

A tree of roles that grants users above a record owner in the hierarchy access to that owner's records, widening access beyond organization-wide defaults without explicit sharing rules.

A rule that opens access to records for users or groups based on record ownership or field criteria, used when organization-wide defaults are more restrictive than the business requires.

A collection of access settings and object permissions assigned to users in addition to their profile, allowing additive grants without creating a new profile for every job variation.

A user's single required baseline setting group that defines default object permissions, page layouts, and login behavior; it establishes the floor that permission sets extend.

The security principle of granting each user only the access needed for their current duties, reducing blast radius when credentials are compromised or an employee changes roles.

Controls that determine whether a user can view or edit a specific field, applied independently of object permissions and enforced across the interface, APIs, and reports.

An authentication pattern where a user logs in once to a central identity provider and is then trusted by connected applications through a standards-based assertion rather than separate credentials.

An XML-based federation standard in which an identity provider issues a signed assertion describing the user, which the service provider validates to establish a session.

An authorization framework that lets a client obtain a scoped access token to call APIs on a user's or integration's behalf without sharing the user's password.

A configuration that registers an external application with the platform, defining its credentials, OAuth scopes, callback URLs, and which users may authorize it.

A resource-oriented HTTP interface using standard verbs and JSON payloads, well suited to synchronous record operations and lightweight integrations between systems.

An XML-based interface with a formal WSDL contract and strict typing, chosen when a partner requires a defined schema, WS-Security, or reliable enterprise messaging semantics.

The overall pattern for connecting systems: choosing synchronous or asynchronous style, defining contract and error handling, and managing authentication, retries, and monitoring.

A publish-subscribe messaging model on the platform where publishers emit event messages and multiple subscribers react asynchronously, decoupling systems and smoothing load spikes.

A design where components communicate by emitting and consuming events rather than calling each other directly, improving decoupling, resilience, and independent scalability.

A property of an operation that produces the same result when repeated, essential for safe retries in integrations where duplicate delivery or network timeouts are expected.

An isolated copy of an org used for development, testing, or training, with a type that determines whether it contains metadata only or metadata plus a sample of data.

The controlled movement of metadata and configuration from a source environment to a target environment, ideally validated in a full or partial copy sandbox before production release.

A packaged collection of metadata components sent from one org to another for deployment, limited to components the platform supports and to connections between related orgs.

The accumulated cost of shortcuts such as hard-coded values, duplicated automation, and untested code, which slows future change and raises regression risk.

A constraint on how a solution performs rather than what it does, covering availability, latency, throughput, security, maintainability, and recovery targets that shape the architecture.

The structured comparison of design options against weighted criteria such as cost, time, risk, and scalability, producing a documented rationale for the recommended approach.

A short document capturing a significant decision, its context, the alternatives considered, and the consequences accepted, giving future reviewers the reasoning behind the design.

A governance group that evaluates proposed solutions against standards, security, and integration policy, and can approve, conditionally approve, or reject the design.

The artifact that states business objectives, scope, data model, integration and security approach, assumptions, and risks, serving as the shared reference for build and review.