GENERAL TEST STRATEGY

• Before trying to come up with an answer, read the question carefully and try to figure out what feature is being tested on.
• At the end of your exam, try to memorize which concepts you felt uncertain about. If you don't pass the first time, you are very likely to see similar questions when you retake.
• When two answers seem plausible, favor the one that makes Salesforce look the best. Said another way, choose the one that shows how Salesforce can support the business need. The exam will often reward knowing which platform features make something possible, and won't ask questions about things that are not possible in Salesforce.
• The correct answer will never be something outside the scope of admin duties. For example, the correct answer will not be "use Apex".

AUTOMATIONS

For automation questions, Flow is usually the right answer. Still, you should pick the simplest tool that solves the problem. Generally, the order (from simplest to most complicated) is:

1. Validation Rule

   When you need to keep data clean before a record is saved, use a Validation Rule.

2. Formula Field

   When you need to calculate data based on other fields on this record or a parent record, use a Formula Field.

3. Roll-Up Summary

   When you need to add up data from child records onto a parent record, use a Roll-Up Summary Field.

4. Flow

   All other automation problems should be solved with Flow.

Automation examples

• Validation Rule: If the Contact's Email Address is not valid, show an error message.
• Formula Field: An admin needs to calculate the days between an Opportunity's Close date and the current date.
• Roll-Up Summary Field: An admin needs to see the total amount of all Opportunities for an Account.

ROLL-UPS

• You can create roll-ups on master-detail relationships, but not regular lookup relationships.
• If a master record is deleted, all child records are deleted.
• If a child record is deleted, the master record is not deleted.

DEPLOYMENT

• For deployment questions, especially when the change could cause a serious error, prefer developing in a sandbox, testing there, then deploying to production with Change Sets.
• Avoid creating flows, validation rules, or other business-critical automation directly in production when the question emphasizes testing, risk, or user impact.

SHARING AND VISIBILITY

• Be sure you understand the difference between record visibility and user permissions. Record visibility controls which individual records a user can see or edit. User permissions control what the user is allowed to do with apps, objects, fields, and system features. A user usually needs both: permission to access the object, and sharing access to the specific record. In rare cases, users may have the "Modify All" or "View All" permission on a specific object, which would override the org-wide default and sharing rules.
• Record Visibility: If the question asks whether a user can see or edit a specific record they do not own, think org-wide defaults, role hierarchy, sharing rules, manual sharing, account teams, opportunity teams, and territory management.
• Account and Opportunity Teams: Use when users collaborate on specific Accounts or Opportunities and need targeted record access without opening access broadly.
• Permission Set Groups: Use when a group of users needs the same extra app, object, field, or system permissions without changing their profiles. Permission set groups do not, by themselves, share individual records.
• Muting Permission Sets: Use when you want to assign most, but not all, permissions from a permission set group. Muting removes specific permissions, such as object, field, app, or system permissions, from that group.
• Profile Changes: Use when everyone with a certain job role needs a baseline level of object, field, app, login, or system access. On the exam, prefer permission sets for additive access unless the question clearly says the baseline profile should change.
• Sharing Rules: Use to automatically open record access based on owner or record criteria, without modifying the org-wide defaults.
• Manual Sharing: Use for one-off or ad-hoc access requests when other options are too broad.

Sharing and Visibility Examples

• Record Visibility: A sales rep needs read-only access to one Account they do not own. Use manual sharing, an Account Team, or another record-sharing feature depending on how repeatable the need is.
• Account and Opportunity Teams: A solution engineer needs access to a specific Opportunity they are helping close, but does not need access to all Opportunities in the region.
• Permission Set Groups: A team working on a pilot program needs access to a custom app, a custom object, and related fields.
• Muting Permission Sets: You want to give a group of users almost all permissions needed for sales operations, but you need to explicitly remove Delete rights for Opportunities even though they're normally in the set.
• Profile Changes: All customer support reps need access to view and edit a new custom object daily as part of their job.
• Sharing Rules: All regional sales teams should have read-only access to Accounts owned by other teams in the same region.
• Manual Sharing: A user requests access to a single high-profile Account record they don't own, just for this quarter.