Quick reminder that today’s class is a demo session with some learning. We’ll be reviewing and demoing the User Management and Data Security project that was given previously. If you worked on it individually or in a group, please come prepared to demo your solution live. Bring • Your laptop • Your Salesforce org open • Your setup ready to explain This is not about perfection. This is about confidence, clarity, and mastery. The more you demo, the more comfortable you become explaining your thinking, your decisions, and your setup. This is exactly how real Salesforce Admin interviews work. Even if you struggled, come and demo. Even if it’s not fully finished, come and demo. Showing your work is how you grow. See you in class and let’s make it interactive and powerful 💪 Kind regards Godwin, Coach & Mentor

🏢 Business Context You are the Salesforce Administrator supporting Tesco UK. Salesforce Sales Cloud is used to manage Accounts and Opportunities for large business customers and strategic suppliers. Multiple teams access Salesforce, and sensitive revenue data must be protected while still allowing sales teams to work efficiently. Your task is to design and implement proper user management and data security, exactly how it would be done in a real organisation. This project focuses strictly on • Users • Profiles • Roles • Record visibility • Field level security 🎯 Project Objective By completing this project, you will demonstrate that you can • Control what users can do • Control what records users can see • Protect sensitive financial data • Test and validate security behaviour This is a portfolio grade project and will be reviewed and demoed. 👥 Teams Using Salesforce Sales Team Finance Team Management 👤 Users In Scope Use the limited Salesforce licenses available in your Developer Org. Your implementation must support the following roles • Sales Executive • Sales Manager • Finance User • Salesforce Administrator 📊 Objects In Scope You will work only with standard Sales Cloud objects • Account • Opportunity No custom objects. No record types. 🧱 Fields You Must Create on Opportunity Create the following custom fields on the Opportunity object. Finance Sensitive Fields These fields must be visible only to Finance Users and the Salesforce Admin. • Forecasted Margin Percentage, Number • Approved Discount Amount, Currency • Finance Internal Notes, Long Text Area Sales Only Fields These fields must be visible to Sales Users and the Salesforce Admin, but hidden from Finance. • Sales Strategy Notes, Long Text Area • Competitor Involved, Checkbox 🔐 Security Requirements Sales Executive • Can create and edit their own Accounts and Opportunities • Can only see Opportunities they own • Cannot see Opportunities owned by other Sales Executives • Cannot see any Finance Sensitive fields

Data Security Meeting Summary Overview This meeting covered Salesforce Data Security, focusing on the five layers of security and their practical implementation in a Salesforce organization. Key Topics Covered 1. Five Layers of Salesforce Security - Object-Level Security — Controls which objects users can access and what actions (create, read, edit, delete) they can perform - Field-Level Security — Restricts view/edit access to specific fields within objects - Record-Level Security — Controls access to individual records - Organization-Level Security — Governs login hours, IP ranges, and password policies across the org - Org-Wide Default (OWD) — Sets baseline record-level access (private, public read-only, public read/write) 2. Object-Level Security Implementation - Configured through user Profiles - Controls permissions for create, read, edit, and delete operations on objects - When permissions are restricted, users cannot perform those actions - Permission Sets are used to grant additional privileges without modifying the base profile 3. Field-Level Security - Controls visibility and editability of specific fields - Two permissions: Read (view) and Edit - If read access is unchecked, the field is completely hidden and cannot be edited - Implemented at the profile level 4. Organization-Level Security - Login Hours — Restricts access to specific times (e.g., 9 AM - 4 PM) - IP Login Ranges — Limits access to specific company locations/networks - Password Policy — Enforces password expiration, complexity, length, and history requirements - Login Lockout — Limits failed login attempts and lockout duration 5. Org-Wide Default (OWD) & Record-Level Access - Private — Users only see their own records - Public Read-Only — Users can view all records but cannot edit - Public Read/Write — Users can view and edit all records - OWD is the baseline; other mechanisms (role hierarchy, sharing rules, manual sharing) can grant additional access

In the last class permission set came up again and a lot of us mix it up on when and were to use it - Permission Sets control what a user can do, not just what they can see. Example: create, edit, delete, run reports, access apps, or use certain features. - - Sharing Rules are only about who can see which records. 💡 Easy way to remember: - Sharing rule= visibility 👀 - Permission Sets = capabilities

part of what we learnt in the last class @Efetobore Igoni - Sharing Rule – automatic sharing for groups or roles (accessed from back-end / admin setup)Use when many people need access to the same type of records - Manual Sharing – share one record with one person (accessed from front-end / record-level)Use when just one person needs access to a specific record Tip: Rule = club entry for everyone, Manual = invite one friend in Someone asked why we can’t use sharing rule for one on one ( putting one user in a group) • Sharing rules are meant for groups of users, not individual exceptions. • Creating a group for just one person is extra admin work for something that manual sharing does instantly. • Manual sharing is quicker, simpler, and clearer for one-off cases. Rule of thumb: • One person → manual sharing • Multiple people → sharing rule