HANDS-ON ACTIVITIES

SHARING & VISIBILITY

FEBRUARY, 2018

Hands-on Activities: Sharing & Visibility 1

1. DECLARATIVE SHARING VIA QUEUES
Identify the core declarative platform features that can be used to meet record-level,
object, and field sharing requirements.

USE CASE OVERVIEW

Universal Containers computers' branch, PCS Computing, is divided into Sales and Service
organizations reporting to the CEO. They are currently using Accounts, Contacts, Cases, and
Opportunities functionality in Salesforce.

• 15,000 Direct Sales representatives are organized hierarchically by geography:

− Executive Vice President (VP) of Global Sales
− Senior VPs of each major region: APAC, EMEA, AMER
− Divisional VPs of each region’s countries (e.g., USA, Canada, etc.). There are 127
countries that PCS Computing operates in.
− District Managers for each major territory/state in each country. There can be up to 30
territories per country, with an average of 10.
− Sales Representatives that report to each District Manager. Sales Reps typically operate
at a city or local region level.
• 10,000 Channel Representatives report to the Executive VP of Global Sales and are
organized by Partner Tiers:
− Premium Partners
− Resellers
• There are over 500 service engineers that form part of a Customer Service
organization that are organized by two major product functions, with a manager of
each major function:
− Hardware
− Software
• Each function has up to 25 specialty teams (e.g., Hardware – Desktops, Hardware –
Laptops, etc.) and users can work in more than one team. A team usually consists of
25 users.
• Sales reps at the city/local region level will own accounts and opportunities.
Reporting will roll-up through their district manager up to the Executive VP of Sales.
• Channel reps will own partner accounts.

Hands-on Activities: Sharing & Visibility 2

 • Opportunities are initially only visible to the Sales Rep that owns the opportunity.
• Users in the Sales organization (Channel and Direct Sales reps) only have access to
the accounts they own as well as to the accounts that are owned by their
subordinates.
• Users should have the same access to contacts as they do to the contact’s related
account.
• Direct Sales reporting needs to roll up from the DM to the Executive VP of Sales.
• Channel Sales reporting rolls up by Partner Tier to the Executive VP of Sales.
• Customer Service engineers reports roll up by product function only: e.g., hardware
and software. There is no requirement to roll up reporting from specialty teams to
the product function level.
• PCS Computing’s service engineers can create cases on behalf of customers for
servicing the products that they have purchased.
• Cases are categorized into two levels:
− Type: Hardware and Software
− Subtype: For each type, there can be multiple related subtypes (e.g., desktops)
• A specialty team will usually work on one or more case subtypes. For example, the
Hardware – Desktops team will usually work on Desktop cases.

DETAILED REQUIREMENTS
• Cases are initially owned by a specialty team but can be assigned to an individual
case owner.
• Cases are visible to the team by default but will only be visible to the case owner and
their manager once assigned.
• When a case is initially created, it will be assigned to members of that specialty
team, based on the combination of type and subtype.

PREREQUISITE SETUP STEPS

• Create the two picklist fields – use arbitrary picklist values for the Subtype field. Set
up Case.Type field with two picklist values – Hardware and Software. Set up
Case.Subtype field with multiple subtypes, e.g., Hardware – Desktop, Accessory,
Monitor, Input Devices etc. Software – Office, Financial, Accounting, Banking, Taxes,
Games, etc.
• Ensure the fields are added to page layouts and profile FLS is present for the field to
be visible.
• Ensure you have created a public group for specialty type and added users to that
public group. We will use this group with queue and declarative sharing later.

Hands-on Activities: Sharing & Visibility 3

CONSIDERATIONS
• Can the requirements be met with a declarative solution?
• Does use of queues constitute the correct solution? In which case may queues not
be the right choice?
• What will be the default OWD for case?
• Is there a need for a separate OWD for internal versus external users?
• How will the visibility of a case be provided to the whole specialty team when the
case is unassigned?
• How will the visibility of a case be restricted when the case is assigned to a specific
team member within the specialty team?
• What will the assignment rule look like for assigning a particular case to a specialty
team?
• How will you provide for a scenario when a case is not matching any assignment
rules and not eligible to be worked on by any specialty team?

Hands-on Activities: Sharing & Visibility 4

SOLUTION
• Queues should be used for each specialty type.
• Case assignment to assign based on subtype field.

DETAIL STEPS FOR SOLUTION

• Set up queues for each specialty Type – Subtype, e.g., Hardware – Desktop.
□ Quick search from Setup for queues and click Queues.
□ Click the New button to create a new queue.
□ Fill out required fields, select object assigned to the queue [e.g., Case] and assign queue
members [e.g., specialty group members either via public group or roles].
□ Repeat for each specialty group you are going to test with.
• Set up assignment rules for the specialty group.
□ Quick search setup for case assignment and click Case Assignment Rules.
□ Click New [provide Name and save].
□ Click the name link [not Edit] of the newly created assignment rule.
□ Click the New button in the Rule Entries section.
□ Fill out required fields and criteria, e.g., assign to this queue when Type = Hardware and
Sub Type = Desktop [for Desktop specialty].
□ In step 3, assign the queue you created in the previous step as target for assignment rule
entry.
□ Save the rule entry and make sure you have made the Assignment Rule Active.

TEST YOUR SOLUTION

• Create a new user and assign the user to a specialty public group.
• Create a new case that matches the case assignment rule to assign to your specialty
queue [choose correct type and sub-type fields when creating the case].
• Log in as the new user and go to the list view for the case. The new case that was
created should be visible in the list view which has the same name as the queue
name [when a queue is created, a corresponding list view with the same name is
automatically created].
• Select the case that was newly created from queue list view and click Accept.
• At this point, the case ownership changes from the queue to the new user and the
case is removed from the queue and assigned to the new user to work on.

Note:
Ensure that all the detailed requirements are met while testing your solution.

Hands-on Activities: Sharing & Visibility 5

2. OWD AND ROLE HIERARCHY
Identify the core declarative platform features that can be used to meet record-level,
object, and field sharing requirements.

USE CASE
Universal Containers comprises Sales and Service organizations. They have Account
Management, Contact Management, Opportunity Management, and Case Management
functionality to be deployed to users. Considering the functionality needed and the
organization structure, administrators would like to set up application security to provide
the right data visibility to the users.

Sales and Service report to the CEO.

• 15,000 Direct Sales representatives are organized hierarchically by geography.

□ Executive Vice President (EVP) of Global Sales
□ Senior VPs of each major region – APAC, EMEA, AMER
□ Divisional VPs of each region’s countries (e.g., USA, Canada, etc.). There are 127
countries that Universal Containers operates in.
□ District Managers for each major territory/state in each country. There can be up to 30
territories per country, with an average of 10.
□ Sales Representatives that report to each District Manager. Sales Reps typically operate at
a city or local region level.
• 10,000 Channel Representatives report to the Executive VP of Global Sales and are
organized by Partner Tiers:
□ Premium Partners
□ Resellers
• There are over 500 service engineers that form part of a Customer Service
organization that are organized by two major product functions, with a manager of
each major function:
□ Hardware
□ Software
• Each function has up to 25 specialty teams (e.g., Hardware – Desktops, Hardware –
Laptops, etc.) and users can work in more than one team. A team usually consists of
25 users.
• Sales reps at the city/local region level will own accounts and opportunities.
Reporting will roll up through their district manager up to the Executive VP of Sales.
• Channel reps will own partner accounts.
• Opportunities are initially only visible to the Sales Rep that owns the opportunity.

Hands-on Activities: Sharing & Visibility 6

 • Users in the Sales organization (Channel and Direct Sales reps) only have access to
the accounts they own, as well as to the accounts that are owned by their
subordinates.
• Users should have the same access to contacts as they do to the contact’s related
account.
• Direct Sales reporting needs to roll up from the DM to the Executive VP of Sales.
• Channel Sales reporting rolls up by Partner Tier to the Executive VP of Sales.
• Customer Service engineer reports roll up by product function only (i.e., hardware
and software). There is no requirement to roll up reporting from specialty teams to
the product function level.

DETAILED REQUIREMENTS
The role hierarchy should be built to the lowest level required (e.g., to the sales rep level),
but you will not need to populate all the roles at each level (e.g., do not populate all
countries or all states in a country). It should be sufficient for demonstration purposes.

PREREQUISITE SETUP STEPS

Prior to configuring the solution in the org, please ensure:

• All actors in the scenario should be assigned appropriate user licenses (Salesforce,
Community, etc.).
• Use an org which is provisioned with Partner Community licenses.

CONSIDERATIONS
The following considerations will guide in you in designing the solution:

1. Who are the different actors?

2. Who are the internal users?
3. Who are the external users?
4. What are the data sets that need sharing?
5. What are the Organization-Wide Defaults (OWD) for the objects?
6. Will every object need an OWD specified?
7. Who is the owner of the records for each of the objects?
8. What are the different approaches to achieving data roll-ups?

Hands-on Activities: Sharing & Visibility 7

SOLUTION
OWD
• Organization-wide sharing defaults set the baseline access for your records.
• The following is the suggested OWD for the objects:
Organization-Wide Defaults (OWD)

Object OWD

Account Private

Contract Controlled by Parent

Opportunity Private

Case Private

ROLE HIERARCHY

• High-level considerations:
□ Every user that owns application data must be assigned to a role, as it impacts visibility,
roll-up, and other displays based on roles.
□ To avoid performance issues, no single user should own more than 10,000 records of an
object. Users who need to own more than that number of objects should either not be
assigned a role or placed in a separate role at the top of the hierarchy. It’s also important
to keep that user out of public groups that might be used as the source for sharing rules.
• An indicative role hierarchy to the necessary depth should be built. Width (e.g.,
countries) should be representative but not exhaustive.
• The following is the suggested role hierarchy:

Hands-on Activities: Sharing & Visibility 8

 • There should be no roles for specialty teams. This functionality can be satisfied by
Case Queues.
□ If a role was created for specialty teams, then additionally, sharing rules would have to be
configured to provide users access to cases across specialties.
• In a Private OWD model for Opportunities and Cases, Account Owner can get access
to related Opportunities and Cases, by configuring No / View All / Edit All settings
on the role.
•

Hands-on Activities: Sharing & Visibility 9

3. DATA MODEL
Identify the core declarative platform features that can be used to meet record-level,
object, and field sharing requirements.

USE CASE
Universal Containers comprises Sales and Service organizations. They have Account
Management, Contact Management, Opportunity Management, and Case Management
functionality to be deployed to users. Considering the functionality needed and the
organization structure, administrators would like to set up application security to provide
the right data visibility to the users.

DETAILED REQUIREMENTS
The role hierarchy should be built to the lowest level required (e.g., to the sales rep level),
but you will not need to populate all the roles at each level (e.g., do not populate all
countries or all states in a country). It should be sufficient for demonstration purposes.

• Users in Universal Containers' Sales organization need to be able to associate

industries to an account. Each account can be related to one or more industries.
• If the user has access to the account, they will also have access to the industries
related to the account.
• Only system administrators can create and edit a master set of industries.
• A master industry has industry-specific fields, such as SIC code and parent industry,
and should be visible when viewing an account industry record.
• Administrators need to be able to report on and view all accounts that a particular
industry is related to.

PREREQUISITE SETUP STEPS

Prior to configuring the solution in the org, please ensure:

• All actors in the scenario should be assigned appropriate user licenses; for example,
Salesforce, Community, etc.
• Use an org which is provisioned with Partner Community licenses.

Hands-on Activities: Sharing & Visibility 10

CONSIDERATIONS
The following considerations will guide in you in designing the solution:

1. Who are the different actors?

2. Who are the internal users?

3. Who are the external users?

4. What are the data sets that need sharing?

5. What are the Organization-Wide Defaults (OWD) for the objects?

6. Will every object need an OWD specified?

7. Who is the owner of the records for each of the objects?

8. What are the different approaches to achieving data roll-ups?

Hands-on Activities: Sharing & Visibility 11

SOLUTION
The following is the suggested solution:

OBJECTS:
• Create a custom object (Industries) that will hold the list of Industries.
− Field: Industry (Name)
− Field: SIC Code [Text]
− Field: Parent Industry [Lookup (Industry)]
− Field: ….
− OWD: Public ReadOnly
− Only Administrators will have Profile / Permission Set to Create and Edit for Industries
− Administrators will have Profile set to "View All" on Industries
• Create a custom object (Account Industry) that will list Industries associated with a
particular Account.
− Field: Account [Master-Detail (Account)]
− Field: Industry [Lookup (Industry)]
− Field: ….
− OWD: Controlled By Parent

DATA MODEL:
• The following is the data model for the solution:

• When OWD for Account Industries is set to Controlled By Parent and Parent
Account has OWD set as Private, the users that have access to the Account will be
able to access the related Account Industries.
• Create a report type of Account Industries with Accounts with a filter on Industry.

Hands-on Activities: Sharing & Visibility 12

 ADDITIONAL ACTIVITIES
To practice these activities, you can leverage one of your Playgrounds or
other resources, if needed:

 Use your existing Developer org.

 Sign up for a free Developer Edition account here.

1. CREATE USERS DECLARATIVELY

In this step, you create a user who reports to the user you first created when signing up
for the organization. Use this configuration to ensure that when this new user creates an
invoice meeting certain conditions, it’s routed to the manager.

1. From Setup, click Manage Users > Users.

2. On the All Users page, click New User.
3. Enter the following information:
• In First Name, enter Bob.
• In Last Name, enter Smith.
• In Alias, enter bSmith.
• In Email, enter your own email address, so that you will receive the approval
requests routed to Bob Smith.
• The Username defaults to your email address, but you’ll need to create a unique
username for Bob, in the form of an imaginary email address.
Write down Bob’s username (his imaginary email address) because you’ll log in as him
shortly.

• In Manager, select the user you created when you signed up for your organization.
You can use the magnifying glass to search for the user.
• In User License, select Salesforce.

4. Click Save. You will receive an email confirming the creation of the new user. You still
need to configure authorizations, so don’t log in as Bob Smith yet or you’ll have to
immediately log back in as the administrator.

Hands-on Activities: Sharing & Visibility 13

2. CREATE USERS PROGRAMMATICALLY WITH THE REST API
In this tutorial use the Workbench tool to query for existing users and use the
information to create a new user with the REST API.

1. Log into Workbench and run a query to find Bob Smith, the user you created in
the previous activity.
• Type or paste the following URL into your browser:
https://developer.salesforce.com/page/Workbench
• Leave the default Workbench settings, accept the terms of service, and click Login
with Salesforce.
• Check that the Logged in as user in the top right-hand corner of the screen is the
administrator of your Developer Edition organization. If it isn’t, click (Not you?)
and log in as the administrator of the Developer Edition organization.
• Click Allow on the “requesting permission” screen.
• In the workbench menu, select queries > SOQL Query.
• Choose Profile in Object.
• Select Idand Namein the Fields selection box. You can select more than one field by
holding down the CTRL key and clicking the field names.
• Filter results by Name = Standard User.
• Click Query.
• Copy the Id of the Standard User Profile to an ASCII text editor such as Notepad.
The Id will be used later when creating the new user.

2. Now use the REST API in Workbench to retrieve Bob Smith’s information.
• In the workbench menu, select utilities > REST Explorer.
• Click Execute next to /services/data.
• Click the most recent release.
• Click url: /services/data/v{version#}.
• Click recent: /services/data/v{version#}/recent.
• Click Bob Smith.
• Click attributes.
• Click url: /services/data/v{version#}/sobjects/User/Bob Smith’s user Id.
• Click Show Raw Response.
• Copy everything in Raw Response between the curly brackets ({}) and paste it into
an ASCII text editor such as Notepad.
The text between the curly brackets is a JSON object representation of Bob Smith’s
information

Hands-on Activities: Sharing & Visibility 14