Your organization has a group of users called “Contract Reviewers”. They should be able to view and edit all contracts in Salesforce, regardless of who owns them, but they should not be able to delete any contracts. How would you ensure that this group has the correct access to the Contract object?
To give the “Contract Reviewers” the ability to view all contracts, regardless of ownership, but not delete them:
1. Profiles:
– Go to the profile associated with the “Contract Reviewers” group.
– Locate the Contract object permissions.
– Ensure the “Read” and “Edit” permissions are checked.
– Also, ensure that “View All” is checked, so they can view all contracts.
– Ensure “Delete” and “Modify All” are unchecked, so they cannot delete contracts or override other specific permissions.
2. Object Settings:
– Verify in object settings that they have access to the Contract object and its related lists, page layouts, and other associated components.
Using “View All” gives users the ability to view all records of an object, whereas “Modify All” would give them full access, including delete permissions. By providing “View All” but not “Modify All”, you ensure they can view and edit but not delete contracts.
You have two teams: Sales and Support. Both teams work with the Account object. The Sales team should see only Accounts where the “Type” is set to “Prospect”, while the Support team should see only Accounts where the “Type” is set to “Customer”. How would you configure this in Salesforce to ensure each team sees only the appropriate Accounts?
1. Profiles:
– Create two profiles: one for Sales and one for Support.
– Ensure both profiles have at least “Read” access to the Account object.
2. Organization-Wide Defaults (OWD):
– Set the OWD for Accounts to “Private”. This ensures that, by default, users can only see Accounts they own.
3. Criteria-Based Sharing Rules:
– For Sales: Create a criteria-based sharing rule where if the “Type” of Account is “Prospect”, share the record with the Sales profile with Read access.
– For Support: Create another criteria-based sharing rule where if the “Type” of Account is “Customer”, share the record with the Support profile with Read access.
A user in your organization should be able to view all the records of the “Lead” object but should not be able to see a specific sensitive field called “Lead Score”. How would you configure this in Salesforce to restrict visibility to the “Lead Score” field for this user?
We can achieve this using Field Level Security
Your organization wants to ensure that while all sales reps can view the ‘Discount’ field on an Opportunity record, only managers can edit it. How would you achieve this?
We would create two page layouts. One layout would have the ‘Discount’ field as read-only, while the other would have it editable. Then, I would assign the read-only layout to the sales rep profile and the editable layout to the manager profile.
Your organization uses a custom object to track Projects. There’s a request to differentiate between ‘Internal’ and ‘Client’ projects, capturing different data sets for each. How do you set this up?
I’d start by creating two record types for the Projects custom object: ‘Internal’ and ‘Client’. Next, I’d design two different page layouts, one tailored for internal projects with its specific fields and another for client projects. Each record type will then be associated with its respective page layout. This way, when users create a new project, they can pick the appropriate record type and get the desired page layout to fill in the relevant details.
In your organization, a new custom object called “Vendor Evaluations” has been created. Members of the “Vendor Management” public group need to have read-only access to all records of this object, but they shouldn’t be able to edit or delete them. How would you ensure this in the Salesforce?
1. Profile Settings:
Ensure the profile associated with the “Vendor Management” group has the “Read” permission for the “Vendor Evaluations” custom object. Ensure “Edit” and “Delete” permissions are unchecked for this profile for the same object.
2. Organization-Wide Defaults (OWD):
– Set the OWD for “Vendor Evaluations” to “Private”. This will ensure that by default, only record owners can access the records they own.
3. Sharing Rules:
– Create a new sharing rule for the “Vendor Evaluations” object.
– Share the records with the “Vendor Management” public group and grant them “Read Only” access.
How would you set up Salesforce to allow an Account Manager to automatically share an Account with an Account Executive and a Pre-sales Consultant, ensuring that the Account Executive has read/write access, but the Pre-sales Consultant has read-only access, all while keeping the default Account sharing setting to ‘Private’ in OWD?
1. Organization-Wide Defaults (OWD) for Accounts:
– Set the OWD for Accounts to `Private`. This means that by default, users can’t see each other’s Accounts unless explicitly shared.
2. Configure Account Teams:
– In `Setup`, search for `Account Teams` and click on `Set Up Account Teams`.
– Enable Account Teams by checking the ‘Enable Account Teams’ checkbox.
– Under ‘Team Roles’, add roles like ‘Account Manager’, ‘Account Executive’, and ‘Pre-sales Consultant’.
3. Define Account Team Member Access:
– Still on the `Account Teams` setup page, in the ‘Default Account Team’ section, you can specify default access levels for each role.
– For ‘Account Manager’, you might set Account Access to ‘Read/Write’ (but in this scenario, the Account Manager is likely the Account owner, so they inherently have full access).
– For ‘Account Executive’, set Account Access to ‘Read/Write’.
– For ‘Pre-sales Consultant’, set Account Access to ‘Read Only’.
4. Add Default Account Team for Users:
– Each user can specify their default Account Team in their user settings.
– This ensures that when a user (like an Account Manager) creates a new Account, the specified team members (Account Executive and Pre-sales Consultant) are automatically added to the Account with the predefined access levels.
5. Manually Add Account Teams to Existing Accounts:
– For Accounts that existed before setting this up, the Account owner (or someone with the appropriate permissions) will need to manually add the Account Team members.
– They would navigate to the Account record, scroll to the ‘Account Team’ related list, and add team members with their respective roles and access levels.
Certainly! Here we go:
Imagine you’re working as a Sales Manager. One of your Account Managers, Alice, is on leave, and she was working on a big account named “MegaCorp”. You want to give temporary access to another Account Manager, Bob, just for the period Alice is on leave. You don’t want to change the ownership of the account or modify any profile or role-based access. How would you achieve this?
We would use Salesforce’s manual sharing feature to grant Bob temporary access to the “MegaCorp” account.
1. Identify the Context:
– Business Need: Temporary access to a specific record without changing ownership.
User Role: Sales Manager with the required permissions to manually share records.
2. Identify the Salesforce Feature: Manual Sharing in Salesforce.
3. Step-by-step Approach:
a. Access the Record:
– Navigate to the specific account, in this case, “MegaCorp”.
b. Use the ‘Sharing’ Button:
– Click on the ‘Sharing’ button typically located at the top of the record detail page. If you don’t see it, ensure you have the necessary permissions.
c. Add the User/Group:
– Click on ‘Add’ to manually share the account. Select “User” and then choose “Bob”.
d. Set the Access Level:
– Define the level of access for Bob, e.g., “Read/Write”.
Your company “TechFuture” recently acquired a smaller firm named “NanoTech.” Employees from NanoTech will now be using the Salesforce instance of TechFuture. You need to ensure a smooth transition for the NanoTech team. They should be able to view and edit only their old accounts and contacts but should not have access to TechFuture’s existing data. How would you achieve this in Salesforce?
1. Identify the Context
– Business Need: Separate data access between TechFuture’s existing team and the newly acquired NanoTech team.
2. Identify the Salesforce Feature:
– Features: Profiles, Role Hierarchy, and Sharing Settings.
3. Step-by-step Approach:
a. Profiles and Roles:
– Create a custom profile for NanoTech users with object-level permissions tailored to their needs.
– Set up a distinct role in the role hierarchy for NanoTech, ensuring it doesn’t inherently have access to TechFuture’s data through the hierarchy.
b. Ownership and Organization-Wide Defaults (OWD):
– Set the OWD for Accounts and Contacts to “Private” so users can only see records they own by default.
c. Sharing Rules:
– If there are specific scenarios where NanoTech team members need to access other NanoTech users’ accounts or contacts, set up sharing rules based on criteria or role hierarchy to grant this access.
You’re the Salesforce admin. The clinic has a multi-step process for patient care starting from appointment booking to treatment completion. Company wants to track the progression of each patient through this process and ensure that cases don’t fall through the cracks. They want the ability for their staff to visually see the stages each patient is in and easily move them from one stage to the next. What solution would you suggest in Salesforce?
We would implement the Salesforce’s “Kanban” view for Cases.
Absolutely, let’s delve into a comprehensive scenario that encompasses all these elements:
Imagine you are the Salesforce Admin for “SpaceTech Innovations,” a space exploration company. The company has various teams working on different projects. One such project is “Project Mars,” which is confidential and involves a team of scientists and engineers. Only the members of the “Project Mars” team and select executive members should have access to this project’s data. However, for collaboration purposes, sometimes the Project Lead might need to manually share certain information with external consultants. Describe how you would configure Salesforce to satisfy these requirements.
a. Organization-Wide Defaults
– Set the OWD for the “Mars_Project” object to “Private.” This ensures that by default, no one, except the record owner and users higher in the role hierarchy, can see the records.
b. Profiles & Permission Sets:
– Profile: Create a profile “Mars Project Team Member” which has read, create, and edit access to the “Mars_Project” object.
– Permission Set: Create a permission set “Mars Project Exec Access” which provides view access to specific confidential fields that only the executives should see.
c. Public Groups & Sharing Rules
– Public Group: Create a public group “Mars Team” and add all the members of the Project Mars team to this group.
– Sharing Rule: create a criteria-based sharing rule on the “Mars_Project” object that provides ‘Read/Write’ access to the “Mars Team” public group.
d. Teams:
– Set up a “Mars Project Team” on the Mars_Project record where specific roles within the project can be defined, like Project Lead, Scientist, Engineer, etc.
e. Manual Sharing:
– If the Project Lead needs to share specific records with someone not included in the sharing rule (like an external consultant), they can use manual sharing to grant them temporary access.
How to trigger Sharing rule of Formula field?
Sharing rule does not let you use formula fields in the rule criteria, but workaround is to replace the formula field with a regular field and put the formula that populates it into a workflow that fires whenever an object is created or edited. That way you’ll have a regular field with the same value.
example- There is a city (formula field) on Student_c object and we need to use that in the criteria that when City = ‘Delhi’ then share with Sales Support
. Now because we cannot access formula field in the sharing rule so we will create another field on student object, lets say CityValue. Now we will create a workflow that whenever City (formulaField)= ‘Delhi’ then fieldUpdate CityValue (TextField) to ‘Delhi’. Then access the CityValue field in the Sharing rule.
What is the difference between hiding the field from page layout and hiding the field from field level security?
When we hide the field from page layout it is just not visible from that page, but it can be visible from reports, search results, list views, related lists, email and mail merge templates, custom links or with API names in the code.
Whereas if we hide the field from field-level security, then it is not visible from anywhere.
In a sales organization, managers want a standardized list view of “Top Leads” visible to all sales reps. A user with the “Manage Public List Views” permission can create this view and make it public for all sales reps to use. This ensures that everyone is working off the same criteria for top leads.
Manage Public List Views
“Manage Public List Views” is a permission in Salesforce that allows users to create, modify, and delete public list views. List views are basically filtered lists of records of a specific object type (like Accounts, Contacts, Leads, etc.) that help users quickly see specific subsets of their data.
Public vs. Private List Views:
Private List Views: Only visible to the creator.
Public List Views: Visible to all users. However, the ability to create or modify public list views is governed by permissions.
Is it possible to restrict permission for users using permission set?
ANS: No, Permission Set always extends the permission. It does not restrict permission to users.
If a user does not have access to a specific record type, will they be able to see the records that have that record type?
Yes, Record type controls only visibility of record on UI but not its access to users. If user does not have access to record type then user will not be able to create records for that record type using UI. But user will we able to see records if they have appropriate permission to do so.
In Profile settings, what is difference between “Modify All Data” and “Modify All” ?
ANS: Modify All Data : Read, Create, edit, delete, view all and modify all for current Profile, regardless of sharing
settings.
Modify All : Give Read, Edit, Delete and View All permission to selected Object, Create permission is not included in Modify All permission.
Your company has expanded its global operations and now has sales teams in three regions: North America (NA), Europe (EU), and Asia Pacific (APAC). Each region has its own Sales Director, and under each director, there are multiple Sales Managers. Each Sales Manager leads a team of Sales Representatives.
Your objective is to set up a Role Hierarchy in Salesforce such that:
1. A Sales Representative can view only their own records.
2. Sales Managers can view all records owned by Sales Representatives in their team.
3. Sales Directors can view all records in their region.
4. The Vice President of Sales at the head office should have visibility into all records across all regions.
Design a role hierarchy to achieve this.
I would set up the Role Hierarchy as follows:
– Vice President of Sales
– NA Sales Director
– NA Sales Manager 1
– NA Sales Rep 1
– NA Sales Rep 2
– NA Sales Manager 2
– EU Sales Director
– EU Sales Manager 1
– EU Sales Rep 1
– EU Sales Rep 2
– APAC Sales Director
1. Start Top-Down: Always start by defining the highest level in the hierarchy. In this case, it’s the Vice President of Sales.
2. Regional: The next step is to consider significant geographic or organizational divisions. Here, we divided based on regions NA, EU, and APAC. Each region’s head (Sales Director) falls directly under the VP.
3. Functional: Within each region, roles might differ based on functions or responsibilities. In our scenario, it’s the Sales Managers under each Director.
4. Individual Contributors: At the bottom of the hierarchy, we place individual contributors, in this case, Sales Representatives. They report to their respective managers.
5. Record Access Flow: Salesforce’s role hierarchy allows records to roll up. So, a manager (or anyone above in the hierarchy) can see the records of those below them. This means the VP can see everything, the Sales Directors see everything in their region, the Sales Managers see everything in their team, and the Sales Reps see only their records.
6. OWD Settings: To complete this setup, the OWD (Organization-Wide Defaults) for the relevant objects should be set to “Private“. This ensures that the base level access is that users can only see their own records, and visibility only expands based on the hierarchy and any sharing rules or manual sharing in place.
