Do you need to share data dynamically in Salesforce based on the attributes of the data itself? This blog entry shows you how to implement two common dynamic sharing use cases.

Most of us are very familiar with the role hierarchy and sharing rules that administrators use to make data appropriately visible to people based on their position in the company or membership in a work group.

These arrangements are mostly static and implement use cases like:

• All the work of sales engineers should roll up to sales executives.
• The product team should be able to see all cases filed by customers.

Dynamic, Data-Dependent Visibility

Sometimes, the business rules that determine who should see a record are more complex and depend on the data itself.

For example:

• Use Case #1: If an opportunity has an Amount that is greater than $500,000, alert the “Top Deals” team.
• Use Case #2: If a customer case is escalated beyond Tier 2 support, add the account executive and the renewals manager to that case.

The Salesforce platform gives you all the tools, including criteria-based sharing and Apex managed sharing, you need to satisfy these business requirements.

Let’s use our two use cases to outline some guidelines for choosing between those sharing options.

Use Case #1: Dynamic Sharing to a Fixed Set of Users

Visibility is determined by data that could change (Amount), but the people who should gain access to that data (the Top Deals team) remain the same.

The Solution

A criteria-based sharing rule that both uses the Amount field as the criterion for sharing and provides access to a public group containing all Top Deals team members would be a great solution.

Put It Into Action

To create a criteria-based sharing rule:

1. Log in to your org.
2. Click Setup | Security Controls | Sharing Settings.
3. In the target object’s Sharing Rules section of the page, click New.
4. For Rule Type, make sure to select Based on Criteria and complete the remainder of the form.

Use Case #2: Data-driven Access for Specific Users

Visibility is determined by data that could change (Escalation Level), and the users who should be given access are also data dependent (the account executive and renewals manager associated to the Account).

The Solution

Here, an update trigger on the Case object that uses Apex managed sharing would work well. The purpose of the trigger would be to:

• Identify the account executive and renewals manager on the account
• Write two manual shares to the case sharing table, extending access to the case directly to these users.

Put It Into Action

To create an update trigger for a standard object:

1. Log in to your sandbox org.
2. Click Setup | Customize | <target object> | Triggers | New.
3. For <events> in the trigger template, make sure to use the before update or after update event.

To create a trigger for a custom object:

1. Log in to your sandbox org.
2. Click Setup | Create | Objects | <target object>.
3. In the Triggers section, click New.
4. See the note above about the before update event.

You’ll also need to create a unit test for the trigger. Once you have things working properly, you can move the metadata for both the trigger and unit test to production.

Summary

When considering the best data access solution for your own organization, look closely at:

• The users you would like to share data with and the roles for those users
• Data dependencies for users and records
• The Salesforce platform’s sharing solutions and how they can meet your business needs.

Related Resources

• Understanding Sharing
• Understanding Apex Managed Sharing
• Using Apex Managed Sharing to Create Custom Record Sharing Logic
• Criteria-Based Sharing Rules Overview
• Architect Core Resources
• An Overview of Force.com Security

About the Author and CCE Technical Enablement

Bud Vieira is a member of the Technical Enablement team within the salesforce.com Customer-Centric Engineering group. The team’s mission is to help customers understand how to implement technically sound salesforce.com solutions. Check out all of the resources that this team maintains on the Architect Core Resources page of Developer Force.