Salesforce Admin Interview Questions and Answers.
Q1. What is a Profile in Salesforce?
Profiles determine what users can do in Salesforce. They come with a set of permissions which grant access to particular objects, fields, tabs, and records. Each user can have only one profile.
Q2. What is a Role in Salesforce?
Roles determine what users can see in Salesforce based on where they are located in the role hierarchy. Users at the top of the hierarchy can see all the data owned by users below them. Users at lower levels can’t see data owned by users above them, or in other branches, unless sharing rules grant them access. Roles are optional but each user can have only one.
Q3. Explain Organization-wide defaults?
Organization-wide defaults (OWD) specify the default level of access users have to each others records. You use organization–wide sharing settings to lock down your data to the most restrictive level, and then use the other sharing tools to selectively give access to other users. For example, you can give all employees access to an object called Candidate to allow anyone to add a candidate to the database. But you can restrict access to Positions so that anyone can see the jobs available but only the employees with the proper permissions can edit them. OWD can be Private, Public Read Only, Public Read/Write or Controlled by Parent.
Q4. What is Role Hierarchy?
Role Hierarchy open up access to those higher in the hierarchy so they inherit access to all records owned by users below them in the hierarchy. Each role in the hierarchy represents a level of data access that a user or group of users needs. For example, you can restrict access to Candidates by setting the organization–wide default to Private, but allow recruiters to view and edit the candidate records that they own.
Q5. What are Sharing Rules?
Sharing Rules enable you to make automatic exceptions to organization–wide defaults for particular groups of users, to give them access to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give more users access to records—they can’t be stricter than your organization–wide default settings.
Q6. What is Manual Sharing?
Manual Sharing allows owners of particular records to share them with other users.
Q7. What is the use of Grant Access Using Hierarchies checkbox for a custom object?
Grant Access Using Hierarchies checkbox for a custom object is use to grant access to record to users who are above the record owner in role hierarchy. Unchecking the checkbox will make sure that users that are higher in the role hierarchy don’t receive automatic access.
Q8. What is Salesforce Identity?
Salesforce Identity is an identity and access management (IAM) service the lets you give the right people the right access to the right resources at the right time. You control who can access your orgs and who can use apps running on the Salesforce Platform, on-premises, in other clouds, and on mobile devices.
Q9. What is Single Sign-On?
Single sign-on (SSO) lets users access all authorized resources without logging in separately to each one—and without having to create (and remember) different user credentials for each app.
Q10. What is Social Sign-On?
Social sign-on allows users to log in to a Salesforce org with their username and password from an external authentication provider like Facebook, Twitter, LinkedIn, or Google.
Q11. What are Governor Limits in Salesforce?
Because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces limits so that runaway Apex code or processes don’t monopolize shared resources. If some Apex code exceeds a limit, the associated governor issues a runtime exception that can’t be handled.
You can specify users to receive an email notification when they invoke Apex code that surpasses 50% of allocated governor limits. Only per-request limits are checked for sending email warnings; per-org limits like concurrent long-running requests are not checked. These email notifications do not count against the daily single email limit.
Some of the Key Governor limits are:
|Governor Limit Description||Synchronous Limit||Asynchronous Limit|
|Total number of SOQL queries||100||200|
|Total number of records retrieved by SOQL queries||50,000|
|Total number of SOSL queries||2,000|
|Total number of DML statements||150|
|Total number of callouts (HTTP requests or web services calls)||100|
|Maximum CPU time on the Salesforce servers||10 seconds||60 seconds|
|Maximum execution time for each Apex transaction||10 minutes|
Q12. What is Salesforce Login Flow?
A login flow is used to direct users through a custom login process before they can access Salesforce org or Experience Cloud site. Login flow can be used to control the business processes to be followed when users log in to Salesforce. After Salesforce authenticates a user, the login flow directs the user through a process, such as enforcing strong authentication or collecting user information. When users complete the login flow successfully, they’re redirected to their Salesforce org or site. If unsuccessful, the flow can log out users immediately. Custom Login Flows can be created using Flow Builder or Visualforce.
Q13. What is Salesforce Flow?
Flow is an automation tool to collect data and performs actions in your Salesforce org or an external system. You can create Flows using Flow Builder. Salesforce Flow provides two types of flows:
- Screen Flows – guide users through a business process, capture users input
- Autolaunched Flows – launched when a record changes or user clicks a button
- Record-Triggered Flow – launches when a record is created, updated or deleted
- Schedule-Triggered Flow – launched at a specified time and frequency for each record in a batch
- Platform Event -Triggered Flow – launches when a platform message is received
- Autolaunched Flow (No Trigger) – launches when invoked by Apex, processes, REST API and more
Q14. List the Flow Types supported in Flow Builder.
Following flow types are supported in Flow Builder:
- Screen Flow
- Autolaunched Flow with No Flow Trigger
- Autolaunched Flow with a Schedule Trigger
- Autolaunched Flow with a Record Trigger
- User Provisioning Flow
- Field Service Mobile Flow
- Field Service Embedded Flow
- Contact Request Flow
- Checkout Flow
- Orchestrator (Beta)
Q15. List various Flow Distribution Methods.
Flows can be distributed (made available to users) via:
- Flow actions
- Lightning pages
- Experience Builder pages
- Custom Aura components
- Custom Lightning web components
- Custom buttons or custom links
- Flow Orchestrator (Beta)
- Web tabs
- Direct flow URLs
- Visualforce pages
- Lightning Out
- Embedded Service deployments