Salesforce Platform Administrator II Course Notes

Exam weight: 20%. Separate access into layers: user/license eligibility; object/field permissions; then record-level sharing. Record sharing can open a record but does not grant missing object or field permission. Use profiles as the baseline and permission sets for additive task-based access. Permission set groups bundle sets; a muting permission set suppresses permissions contributed through that group. OWD is the record-access baseline. Role hierarchy, sharing rules, teams, territories, and manual sharing can open access; they do not make access more restrictive than the baseline. Field-level security controls field visibility/editability across the platform; page layouts are presentation, not a security boundary.

• Trying to fix a field-permission problem with OWD or sharing.

• Read the noun in the requirement: object, field, record, folder, session, or admin scope. It usually identifies the security layer.

Exam weight: 20%. Choose Flow by trigger and interaction: record-triggered for record changes, screen flow for guided UI, schedule-triggered for time-based batches, autolaunched flow for reusable no-UI logic invoked by another mechanism. Before-save record-triggered flow is the first choice for fast updates to fields on the triggering record. After-save is required for related-record actions and many side effects. Scheduled paths defer actions relative to a record-triggering event; schedule-triggered flows scan records on a defined schedule. Subflows centralize reusable logic; avoid copying the same calculations across many flows.

• Choosing screen flow for unattended work or schedule-triggered flow for an immediate record event.

• Classify every automation scenario by trigger, user interaction, timing, data touched, volume, and transaction boundary.

Exam weight: 19%. Lookup is loosely coupled: child can have independent ownership/sharing and lifecycle. Master-detail is tightly coupled: detail inherits ownership/sharing and deleting the master cascades to details. Native roll-up summary fields require master-detail. A junction object typically uses two master-detail relationships to model many-to-many and can store attributes of the association. Reparenting a detail record is controlled by the Allow Reparenting option on the master-detail relationship. Record types control available business processes, picklist values, and page-layout assignments—not record-level security.

• Believing master-detail prevents parent deletion; deleting the master normally deletes detail records.

• Relationship questions usually turn on ownership, sharing, required parent, cascade delete, roll-up, and many-to-many requirements.

Exam weight: 13%. Matching rules define how Salesforce identifies potential duplicates; duplicate rules decide what happens when a match is found. Existing duplicates still require reconciliation/merge. Validation rules reject saves that violate business rules; formulas calculate values. Report filters only change what is displayed—they do not enforce data quality. Data Import Wizard is browser-based and suited to supported common imports; Data Loader is better for larger/complex operations, additional objects, exports, and explicit field mappings. Use external IDs to match source-system identifiers and support upsert/relationship mapping without relying on destination Salesforce IDs known in advance.

• Assuming a duplicate rule automatically cleans up existing duplicates.

• For imports, think: back up, cleanse, map, sample-test, load in dependency order, handle errors, reconcile.

Exam weight: 11%. Products represent what you sell; price books provide product prices. Opportunities can include products; quotes present deal pricing; orders represent committed or fulfilled purchases depending on process design. Forecasting summarizes expected revenue or quantities against a forecasting hierarchy and configured forecast types; territories organize account/lead coverage and can grant territory-based access. Sales territories can be modeled hierarchically and assigned by rules using attributes such as geography, revenue, industry, or other criteria—do not reduce territory management to geography alone. Account teams are named users collaborating on a specific account with team roles and defined record access; they are not a collection of accounts.

• Treating territories as just geographic labels or confusing them with account teams.

• Sales scenario: identify whether the problem is product/pricing, pipeline/forecast, or coverage/territory.

Exam weight: 10%. Setup Audit Trail answers 'who changed Setup/configuration, what changed, and when.' Use it for metadata/configuration changes rather than record-field history. Field History Tracking records changes to selected tracked fields after tracking is enabled; it cannot retroactively prove changes to fields that were not tracked. Login History answers authentication/login questions. Event Monitoring provides richer event activity, for supported/licensed event types, such as API and user activity. Debug logs help troubleshoot transaction execution, Apex, automation, and runtime behavior; they are not a substitute for Setup Audit Trail.

• Using Event Monitoring as the answer to every audit question.

• Setup change? Setup Audit Trail. Tracked field value? Field History. Login? Login History. API/user event? Event Monitoring. Runtime/automation? Debug logs.

Exam weight: 7%. Developer sandbox: metadata/configuration copy for isolated development and testing. Developer Pro adds more storage for larger development, integration, or QA datasets. Partial Copy includes metadata plus a sandbox-template-selected sample of production data; useful for UAT, integration testing, and training. Full sandbox is a production replica including data and is the standard sandbox type for staging, performance, and load testing. Change sets move supported metadata between connected orgs; account for dependencies, profiles/permissions, tests, and post-deployment configuration that change sets do not automatically solve.

• Treating all sandbox types as equivalent.

• Sandbox selection depends on the fidelity and data volume needed for the test—not simply 'dev vs prod.'