Module 2 — Administration

A Salesforce administrator translates business requirements into a working CRM configuration. The administrator manages users and access, maintains data quality, configures objects and automation, creates reports, supports users, and coordinates safe changes between environments. An admin should first understand the business process, then configure the simplest maintainable solution.

An org is a company's Salesforce environment, including its data, configuration, users, and security settings. Production contains live business data. Sandboxes are copies used for development, testing, and training. Setup is the administration area where configuration is managed, while the App Launcher and navigation expose business applications to users.

A user is an individual who can log in to Salesforce. Creating a user includes choosing a username, license, profile, role, locale, time zone, and email settings. Administrators should deactivate users who leave the company rather than deleting them, because their historical records and audit information must remain available.

A profile provides a user's baseline permissions. It can control object permissions, field-level security, app access, tab visibility, record types, login hours, and login IP ranges. Object permissions include Create, Read, Edit, and Delete (CRUD). Profiles should provide the minimum common access for a group of users.

Permission sets add extra access to selected users without changing their profile. Permission set groups bundle related permission sets for a job function. This creates a flexible access model: profiles define the baseline, and permission sets grant exceptional or additional capabilities. Remove unused permissions regularly because access should be intentional.

Roles primarily control record visibility through the role hierarchy and help organize users for reporting. A manager normally gains access to records owned by users below them, subject to the organization's sharing settings. A role is not the same as a profile: the profile controls what a user can do, while the role helps determine which records the user can see.

Organization-wide defaults define the starting level of record access for each object. Settings such as Private, Public Read Only, and Public Read/Write establish the baseline. A common design principle is to begin with the most restrictive reasonable setting and open access using the role hierarchy and sharing tools.

Sharing rules grant additional record access based on ownership or criteria. They can share records with roles, roles and subordinates, public groups, territories, or queues. Manual sharing and account, opportunity, or case teams handle individual or collaborative exceptions. Sharing rules do not remove access; they extend it.

Public groups collect users, roles, or other groups for sharing and notifications. Queues hold records that a team can take ownership of, which is useful for leads and cases. Assignment rules can automatically route new leads or cases based on field values such as country, product, or priority.

Administrators configure objects to match the business vocabulary. Fields can be text, number, currency, date, checkbox, picklist, formula, roll-up summary, or relationship fields. A good field design uses clear labels, helpful descriptions, correct data types, and controlled picklist values rather than free text where possible.

Page layouts control which fields, related lists, buttons, and actions appear on a record page. Lightning App Builder controls the broader page composition and component placement. Compact layouts show key fields in highlights areas. These layers work together: the layout controls record details, while the Lightning page controls the experience around them.

Record types support different processes, picklist values, and page layouts for the same object. They are useful when teams follow genuinely different workflows, but they should not be created merely to solve a small layout difference. Business processes define values for objects such as sales stages, lead statuses, and case statuses.

Validation rules prevent a record from being saved when a business condition is not met. A formula evaluates to true when the data is invalid, and an error message tells the user how to correct it. Validation should protect data quality without blocking legitimate exceptions. Required fields and validation rules solve different problems: required fields enforce presence, while validation enforces a relationship between values.

Formula fields calculate values from other fields at runtime and do not store a separate value. Roll-up summary fields calculate values such as SUM, COUNT, MIN, or MAX from related child records in a master-detail relationship. Both reduce manual entry and make information visible for reporting.

Flow is Salesforce's primary declarative automation tool. Record-triggered Flows run when records are created, updated, or deleted. Screen Flows guide users through a process. Scheduled paths run actions at a future time, and autolaunched Flows run from other automation or code. A Flow commonly uses Get Records, Decision, Assignment, Create Records, Update Records, and Action elements.

A reliable Flow has a clear entry condition, uses the correct before-save or after-save behavior, avoids unnecessary queries and updates, and handles error paths. Before-save Flows are efficient for updating the triggering record. After-save Flows are used when creating related records, sending notifications, or performing actions. Admins should test create, update, bulk, and fault scenarios.

Several Salesforce features can act during a save, including validation rules, Flows, approval processes, and Apex. Understanding the order of execution helps explain unexpected results and prevents duplicate automation. Before adding a new rule, an admin should check existing Flows, workflows, processes, triggers, and validation rules on the object.

Approval processes route records to designated approvers and track whether they are approved, rejected, or recalled. Entry criteria determine which records require approval. Approval actions can lock records, update fields, send notifications, and perform follow-up actions. Flow-based approvals may be preferred for newer, more flexible processes.

Administrators use tools such as Data Import Wizard and Data Loader to load, update, export, and delete data. Before importing, prepare a clean file, map fields, identify external IDs, handle required fields, and test with a small sample. Duplicate rules, matching rules, validation, and ownership checks help maintain quality. Always back up data before a large update.

Reports answer questions about Salesforce data using filters, grouping, summaries, and formulas. Dashboards display report results as charts, tables, metrics, and gauges. Administrators should define the business question first, use a suitable report type, confirm record visibility, and schedule or subscribe users to important reports.

Administrators monitor login history, setup audit trail, field history, Flow errors, failed jobs, storage, and data quality. When something breaks, reproduce the issue, identify the record and user context, inspect automation and permissions, make the smallest correction, and document the result. Debugging should distinguish a permissions problem from a validation, data, or automation problem.

Configuration changes should be planned, documented, tested, reviewed, and deployed using a controlled process. Sandboxes, change sets, Salesforce CLI, and source control can support deployments. A deployment checklist should include dependencies, test data, user communication, rollback considerations, and post-release verification.

Good administration is secure, simple, documented, and measurable. Use least privilege, clear naming conventions, descriptions, reusable permission sets, controlled picklists, one automation tool per requirement, and regular cleanup. Avoid creating fields, rules, or record types without a business owner and a defined purpose.