Plat-Arch-205 Salesforce Certified Platform Sharing and Visibility Architect Exam Topics and Questions

This is the heaviest topic on the exam, and it earns that weight by testing the layer most architects get wrong: the difference between what users can see and what they can do. You need to distinguish profile-level controls from permission sets, understand when field-level security overrides object access, and know which UI methods actually enforce security versus merely hiding elements from view.

– Object and field permissions

Object permissions determine whether a user can read, create, edit, or delete records of a given type. Field-level security sits on top of that, restricting visibility and editability at the column level even when object access is granted. The exam will present scenarios where a user has object read but certain fields must remain hidden, or where edit access is required on some fields but not others. You need to know that field-level security is the only declarative control that removes a field from both the API and the UI, and that it applies regardless of profile. Permission sets extend access; they never restrict it. The combination of profiles and permission sets means you must trace the union of all grants to determine effective permissions.

– Hiding data at the UI level

Page layouts, record types, and dynamic forms control what appears on a screen, but none of them enforce security. A field hidden by page layout is still accessible via API, reports, and list views. The distinction between UI convenience and true security is a recurring theme in items. You will see scenarios where stakeholders ask to hide sensitive data and you must decide whether a page layout change is sufficient or whether field-level security is required. Record types can drive different page layouts for different profiles, but the record type itself does not restrict access. Dynamic forms let you show or hide fields based on conditions, but again, this is presentation logic, not a security control.

– Protecting sensitive data

Compliance requirements like PCI, PII, and HIPAA demand that certain data is inaccessible to users who do not need it. Field-level security is the primary mechanism, but you also need to consider encryption at rest, masked fields for partial visibility, and audit trails to prove who accessed what. The exam tests whether you can identify when a business requirement is actually a regulatory one. A request to hide credit card numbers is not a page layout question; it is a field-level security and masking question. You must also know that permission sets can grant access to restricted fields, so your design must account for both the base profile and any sets that might be assigned.

– Programmatic enforcement

Apex runs in system context by default, which means it bypasses sharing rules and field-level security unless you explicitly enforce them. The with sharing keyword enforces record-level sharing but does nothing for field or object permissions. To respect field-level security in Apex, you must use Schema.DescribeFieldResult methods to check isAccessible, isCreateable, or isUpdateable before performing DML. Security.stripInaccessible removes fields the running user cannot access, preventing accidental exposure. The exam will present scenarios where a custom component or batch process must honor the same permissions as the UI, and you need to know which code patterns achieve that.

How Permissions to Standard Objects, Custom Objects, and Fields is tested

At 27 percent, this topic appears in roughly one in four items. Questions present a scenario with multiple user types, each needing different access, and ask you to choose the combination of profile settings, field-level security, and permission sets that satisfies all requirements without over-provisioning. The most common trap is recommending a page layout change when field-level security is required, or assuming that hiding a field in the UI protects it in reports and API calls. You will also see items that describe a compliance obligation and expect you to recognize that masking or encryption is required, not just a permission change. Another frequent error is forgetting that Apex in system context ignores field-level security unless you add explicit checks. Read the scenario for words like 'must not appear in any context' or 'regulatory requirement', which signal true security controls rather than UI convenience.

This is the largest topic by far, representing nearly two out of every five items. Record-level access is where most Salesforce security designs succeed or fail, because the platform offers eight different mechanisms and they interact in non-obvious ways. You need to know when to use organization-wide defaults, role hierarchy, sharing rules, manual sharing, teams, programmatic sharing, or a combination, and you must understand the performance and maintenance cost of each choice.

– Organization-wide defaults and role hierarchy

Organization-wide defaults set the baseline: Private, Public Read Only, or Public Read/Write. The role hierarchy automatically grants read and write access to users above the record owner in the hierarchy, but only when the OWD is Private or Public Read Only. If the OWD is Public Read/Write, the hierarchy adds nothing because everyone already has full access. The exam tests whether you recognize when a role hierarchy is redundant or when it conflicts with a sharing requirement. A common mistake is setting OWD to Public Read/Write and then trying to restrict access by role, which does not work because you cannot take away access you have already granted. You must also know that the hierarchy is automatic and cannot be turned off for standard objects, so if you need to prevent upward access, you must use Private OWD and grant access explicitly through other means.

– Sharing rules and groups

Sharing rules extend access beyond the role hierarchy. They can be based on record owner, or on criteria such as field values. Owner-based rules grant access to records owned by users in one group to users in another group. Criteria-based rules grant access to records that match a filter. Both types require a public group, role, role and subordinates, or territory as the source and target. The exam will present scenarios where you must decide whether a sharing rule is more appropriate than a permission set or a change to OWD. You need to know that sharing rules are additive only; they never restrict access. Groups can be public groups, which you define manually or dynamically, or they can be roles or territories. Dynamic groups recalculate membership on a schedule, which introduces a delay that can be a trap in time-sensitive scenarios.

– Teams, object relationships, and programmatic sharing

Account teams, opportunity teams, and case teams grant access to a specific record and optionally its related records. Each team member is assigned a role that determines their level of access. Teams are useful when access is record-specific and does not follow a predictable pattern that a sharing rule can capture. Object relationships also affect access: a user with access to a parent record can gain access to child records if the child OWD is Controlled by Parent. Lookup relationships do not grant implicit access; only master-detail and some standard relationships do. Programmatic sharing uses Apex to create share records in the share table for an object. This is the most flexible mechanism but also the most expensive in terms of maintenance and performance. You need to know when the declarative options have been exhausted and code is the only answer.

– External users and record access overrides

External users (community, portal, or guest users) operate under different limits and permissions than internal users. They cannot be granted access via role hierarchy because they do not have roles in the internal hierarchy. Sharing sets and external sharing rules are the primary mechanisms for communities. Guest users have extremely limited access and require special handling. Record access overrides, introduced in recent releases, let you bypass the role hierarchy for specific objects, which is useful when you need a flatter access model or when the hierarchy introduces unwanted implicit shares. The exam will present scenarios where external users need access to records owned by internal users, or where a community has complex visibility requirements that cannot be met with standard sharing rules alone.

How Access to Records is tested

With 39 percent of the exam, this topic dominates. Questions describe a business requirement with multiple user groups, each needing different record access, and ask you to select the most efficient combination of OWD, hierarchy, sharing rules, and other mechanisms. The most common error is choosing a sharing rule when OWD should be relaxed, or vice versa. Another trap is recommending manual sharing or teams when a sharing rule would scale better, or suggesting a criteria-based rule when the criteria will change frequently and cause recalculation overhead. You will also see items that introduce external users and expect you to know that role hierarchy does not apply. Performance is a recurring theme: a solution that works for a hundred records may fail for a hundred thousand, and the exam expects you to recognize when a design will hit governor limits or cause long recalculation times. Read carefully for clues about record volume, frequency of change, and whether the requirement is temporary or permanent.

Once you have worked through objects and records, the exam turns to everything else: reports, dashboards, list views, files, content, and metadata. These assets do not follow the same access model as standard and custom objects, so architects often underestimate the effort required to secure them. Each type has its own permission set, sharing model, or folder structure, and the exam expects you to know which mechanism applies to which asset. The weight here is significant enough that you cannot afford to skip this area, but the scope is narrower than the first two topics, so your preparation can be focused. You need to know who can see a report, who can run it, and who can subscribe to it, and those are three different questions with three different answers. The same applies to dashboards, which layer dynamic filtering and running user context on top of report access.

How Access to Other Data is tested

Items in this topic describe a scenario where users need access to reports, dashboards, list views, files, or other non-object data, and ask you to identify the correct permissions or sharing settings. The most common trap is assuming that object access automatically grants report access, or that a user who can see a report can also edit it. Report and dashboard folders have their own sharing model, and you must know the difference between Viewer, Editor, and Manager access. Another frequent error is forgetting that dynamic dashboards run as the viewing user, so the user must have access to the underlying report data, whereas static dashboards run as a specified user and can show data the viewer does not normally see. List views can be private, public, or shared with groups, and the exam will ask you to choose the right visibility setting. Files and content libraries each have their own permissions and sharing rules, and you need to know when to use Salesforce Files versus Content versus attachments.

The final topic asks you to step back from individual mechanisms and evaluate the consequences of your design. A sharing model that works perfectly in a sandbox with a thousand records may collapse in production with a million. License types impose hard limits on which features are available, and a design that assumes unlimited permission sets will fail when you discover that each user can have only a certain number. Testing is the area most architects skip, and the exam punishes that by asking how you would validate a complex sharing model before go-live. This topic is where experience shows. You need to know the governor limits that apply to sharing rules, role hierarchy depth, group membership, and Apex sharing. You must also understand that recalculating sharing after a rule change or a role hierarchy update can take hours or days in a large org, and that some changes lock the org during recalculation.

How Implications of Security Model Choice is tested

Questions present a design that satisfies the functional requirements and ask you to identify the scalability risk, the license limitation, or the testing gap. You might see a scenario with hundreds of sharing rules and be asked whether that will cause performance problems, or a design that relies on criteria-based sharing rules on a high-volume object and be expected to recognize the recalculation cost. License limitations are another focus: some licenses do not support role hierarchy, some restrict the number of permission sets, and some limit the objects that can be shared. The exam expects you to know these limits without a reference guide. Testing questions ask how you would verify that a sharing model works as intended, and the correct answer usually involves a combination of manual checks, reports on sharing records, and automated tests in a full-copy sandbox with production data volumes. The trap is recommending a partial sandbox or a developer org, which will not reveal the performance issues that only appear at scale.