Microsoft Teams meeting Join: https://teams.microsoft.com/meet/39934458197442?p=rrxby18osBhKhBZfxZ Meeting ID: 399 344 581 974 42 Passcode: YB7HR6QB

Meeting Summary: Tuesday Team Gamma -Users Management and Data Security Date: January 13, 2026Duration: 131 minutes Topic: Users Management in Salesforce Key Topics Covered 1. Introduction to Users Management Users management is the process of creating, maintaining, and controlling user access in a Salesforce environment. The session distinguished between: - Front-end users: Customer service representatives, sales representatives, and managers - Back-end users: Salesforce administrators, architects, business analysts, and developers 2. Creating Users - Users must have required fields filled (marked in red) to be created successfully - Username is the most critical field—must be unique, alphanumeric, and follow email format (e.g., name@company.com) - Alias can be arbitrary (3-4 characters) - License assignment is essential—determines which profiles a user can access - Role assignment is optional during user creation 3. Licenses and Profiles - Developer orgs come with 4 Salesforce licenses (the most powerful type) - License type determines available profiles - Profiles define what users can do in the organization—think of them as departments - Every user must have a profile; you cannot exist in Salesforce without one 4. Profile Customization Custom profiles are created by cloning standard profiles. Key customization options include: - Login Hours: Restrict when users can access the system (e.g., 8 AM - 7 PM) - IP Ranges: Limit access to specific office IP addresses - Password Policy: Set expiration periods, complexity requirements, and login attempt limits - System Permissions: Enable features like multi-factor authentication 5. Role Hierarchy - Structures visibility in the organization - Users higher in the role hierarchy can access records of their subordinates - Enables data visibility based on organizational structure 6. Permission Sets - Grant additional privileges without changing the original profile - Useful for temporarily extending user capabilities for specific assignments - Can be assigned with time limits - Avoid giving admin-level permissions (View All Records, Modify All Records, View All Fields) to regular users

I believe it will solve Salesforce problem for me.

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

Alpha Team Meeting Summary Meeting Date: January 29, 2026Duration: 132 minutesTopic: Case Management Automations and Workflows Key Topics Covered 1. Case Management Overview The session began with a recap of previous lessons covering Cases, Service Cloud, Service Console, Record Types, and Support Processes. The instructor explained the complete Salesforce CRM flow—from lead capture through customer complaint handling in Service Cloud via Cases. 2. Queues Queues were reviewed as shared workloads for cases before assignment to agents. A queue is a location where records wait for processing by a group member until a user accepts them. 3. Case Assignment Rules - Automatically assign cases to users or queues based on defined criteria - Important: Only one assignment rule can be active at a time - Rules are evaluated in chronological order - Examples included routing cases by origin (email) or subject keywords (e.g., "installation") - You must check the "Assign using active assignment rules" checkbox when creating cases manually for the rule to trigger 4. Case Auto-Response Rules - Automatically send acknowledgment emails to customers when cases are created - Requires verified organization-wide email addresses in Salesforce - Multiple auto-response rules can be configured to cover various case subjects or origins - Templates are customizable for personalized customer communication 5. Escalation Rules - Automatically escalate cases after specified wait times to ensure SLAs are met - Triggers when cases remain in a certain status (e.g., "New") for a defined period - Can escalate to different users, queues, or managers - Escalated cases are visually marked in the UI with a red indicator - Respects business hours if configured 6. Filter Logic in Rules - Multiple criteria can be combined using "OR" (any condition met) or "AND" (all conditions must be met) - Example: "Case origin = Email OR Phone" means either condition triggers the rule