Visual Workflow Series Part 1: Use Visual Workflow to Share Records Dynamically

Sharing rules are a great way to make sure your records are accessible to groups of users (such as roles and public groups). Unfortunately, sharing rules cannot be used to share records dynamically, such as with a user in a lookup field on a record. Fortunately, this can be done declaratively using one of our favorite tools: Visual Workflow (with some assistance from its sibling, Process Builder!).

Our general approach to this is similar to the function of the Sharing button in Salesforce Classic – we will share a level of access to a specific record with a specific user. This is done through a separate object called objectNameShare for standard objects and customObjectName__Share for custom objects. As long as a share record exists for your user or for a group to which you belong, you’ll have that level of access on a record. Share records have 4 important fields that we’ll worry about:

  • AccessLevel : this is the level of access granted to the user (picklist values are Read, Edit, and All)
  • ParentId : this is the record ID of the record that is being shared
  • RowCause : this is the reason for sharing the record; for custom objects, custom sharing reasons can be created
  • UserOrGroupId : this is the ID of the group or user with which you are sharing the record

N.B. : for standard objects, the naming convention for these fields is slightly different; OpportunityShare, for example, uses OpportunityAccessLevel and OpportunityId instead of the above field. If you’re not sure what to use, navigate to the object in Workbench and click on the Fields folder for that record. Additionally, sharing is only available for objects where the sharing setting is not Public Read/Write.

Let’s get to sharing! Here’s our user story: our sales team often assigns a Subject Matter Expert (SME) on certain opportunities. These SMEs only need read access on the records they are assigned too, and our org does not use Opportunity Teams (see note). Our SMEs are discovering that they do not have access when they are initially assigned to the opportunity and the salesperson has to manually share the opportunity with the SME. Help the sales team share the opportunities with the assigned SME automatically!

First, we’ll create a flow that will create the sharing record. Using a record lookup block, we will look up an Opportunity where the ID is the same as the value we pass in through the process builder. We’ll call that variable OppVar (text variable, input only). We’ll store the ID of the SME in a variable called SMEVar (text variable, private).

Flow SME Share 1

Next, we’ll check to see if the user already has access to the record with another record lookup. We want to look up any OpportunityShare records where the UserOrGroupId is the same as SMEVar and the OpportunityId is equal to OppVar. Save the value of the OpportunityAccessLevel to a variable called Access (text variable, private). Make sure to check the box to Assign null values to the variable if no record is found.

Flow SME Share 2

Now that we’ve found any existing OpportunityShare records, we will add a decision block to check the value of Access; call that block “Does access exist?”. We’ll create an outcome called “Yes” where Access is not null. We can also rename the Default Outcome “No”.

Flow SME Share 3

Our last step for the flow is to create the share record if the decision block has the “No” outcome. We’ll give Read access, set OppVar as the OpportunityId, set Manual as the RowCause, and SMEVar as the UserOrGroupId.

Flow SME Share 4

We’ll save the completed flow as an Autolaunched flow so we can call it through Process Builder, activate the flow, and then create the process itself! We’ll create a process that runs when a record changes. Select Opportunity as the object and run the process whenever records are created or edited.

Flow SME Share 7

In the criteria, we’ll have this process run when the SME field is not null and changes values.

Flow SME Share 8

Our last step before activating is to add the Flow action. Select Flow as the action type, call the step “Share with SME”, and select your autolaunched flow. Set the variable OppVar to the value of the opportunity’s ID. Save the step and activate the flow!

Flow SME Share 9

Congratulations, you’ve accomplished your task! To test, you can populate the SME field on an opportunity, and then click the Sharing button. You can see a value for that user with Read Only access listed as Manual. Give yourself a pat on the back!

Thanks for reading the first post in our Visual Workflow series! Tune in next week for more on Flows!

Have another topic you’d like to see in the future? Send us a tweet! @BeardforceTyler

 

Deep Dive into the Day of the Week Formula

Formula fields: the duct tape of Salesforce… they can do nearly anything: fetch information across objects, perform complicated calculations, concatenate data (to name just a few). Specifically for dates, there are many great functions that can identify the day of the month, the month itself, and the year. What isn’t inherently available is the ability to use a simple function to identify the day of the week. Fortunately, Salesforce (and many Community members and bloggers) have assembled a formula that returns the day of the week.

Let’s take a closer look at the fomula provided by Salesforce. For the purposes of this explanation, we will use dateField as a place holder for a date field.

CASE(

MOD( dateField – DATE( 1900, 1, 7 ), 7 ),

0, “Sunday”,

1, “Monday”,

2, “Tuesday”,

3, “Wednesday”,

4, “Thursday”,

5, “Friday”,

“Saturday”

)

This formula utilizes two functions: CASE() and MOD().

  • CASE(expression, value1, result1, value2, result2,…, elseResult)

This function evaluates an expression (in our formula, the expression is MOD(dateField – DATE(1900, 1, 7), 7) ) and returns a result when the expression equals the corresponding value.

  • MOD(expression, divisor)

This function divides an expression by the divisor (in our formula, the expression dateField – DATE(1900, 1, 7) is being divided by 7) and returns the remainder (a la middle school division). E.g. MOD(12,3) would return 0, as 12 divided by 3 is 4; MOD(25,3) would return 1, because 25 divided by 3 is 8 remainder 1.

So what exactly is the formula doing? Why are we using January 7, 1900? The overall methodology is to find the number of days between any known Sunday in the past (we could use any Sunday after 1/1/1700; 1/7/1900 is simply the most commonly used Sunday) and the desired date to evaluate, divide that number by the number of days in a week, find the remainder and count that many days from Sunday. For example, today’s date (7/5/2017) is 42,913 from 1/7/1900. When we divide 42,913 by 7, we get 6130 remainder 3; 3 days from Sunday is Wednesday, which is the correct day! The CASE part of the formula is what returns the name of the day of the week; you can see above that the result that corresponds with the value 3 is “Wednesday”.

Variation: Next dayOfWeek

Let’s say your organization classifies all new contacts by the Saturday on or after which they were added. To show this easily, you want to create a formula to display the Saturday after the Created Date (provided that the Contact was not created on a Saturday). Let’s work backwards on this one.

Say the created date is today, July 5, 2017. We want to show Saturday, which is 3 days from today.

Wednesday + 3 = Saturday

(day 3) + 3 =  (day 6)

See where we’re headed yet? The variable in the formula will be the number of days to add to the Created Date to show a Saturday; we have already calculated the “day number” above using MOD(); Saturday will be hard-coded as (day) 6. Please note that you’ll need to use the DATEVALUE() function to convert CreatedDate from DateTime to Date.

MOD(DATEVALUE(CreatedDate) – DATE(1900,1,7),7) + x = 6

x = 6 – MOD(DATEVALUE(CreatedDate) – DATE(1900,1,7),7)

So we’ll add x to the Created Date to show the next Saturday: DATEVALUE(CreatedDate)+(6-MOD(DATEVALUE(CreatedDate)-DATE(1900,1,7),7). This works well for cases where the number value of the day of the week is greater than the desired day to show, such as when the record was created Wednesday and we want to show the next Saturday, but if we wanted to show the next Tuesday, we’d end up showing the previous Tuesday (our value for x would be negative). So we’ll add an IF statement to add a week when the desired day of the week has passed in that week: DATEVALUE(CreatedDate)+(6-MOD(DATEVALUE(CreatedDate)-DATE(1900,1,7),7)+IF(6-MOD(DATEVALUE(CreatedDate)-DATE(1900,1,7),7>=6,7,0).

In this case, there is no day in the week after Saturday, so we’re in the clear. But if we classified the contacts by the Sunday of the week they were added, it would be another story. There you have it! It may not be easy on the eyes, but hopefully we’ve helped you to navigate the formula and variation.

Use Case: Login Flow

One potential use case for the Day of the Week formula is the rendering of Login Flows. Our post last week addressed the creation of Login Flows to better guide your users to what they need. What if you need to change the user login experience depending on the day of the week? Now you can do so easily. Simply create a formula in the Flow that determines the “day number” and a decision block that checks that day of the week. If you want to create one path for weekend logins, make the parameters formula = 0 OR formula = 5 OR formula =6. Now you can send special reminders to complete timecards on Fridays, update open opportunities before close for the week, or anything else that can help your users have a better experience.


There are plenty of other great ways to utilize the Day of the Week formula. We hope this post has you thinking of use cases for your own org, and we appreciate you taking the time to read today. Have another topic you’d like to see in the future? Send us a tweet! @BeardforceTyler

Improve Your UX With Login Flows

Raise your hand if you’ve ever had to communicate a down time for a deployment to your users or struggled to distribute documentation for a new custom object in a way that was guaranteed to reach all of your users. Did you know you can change the login behavior for users using Visual Workflow (Flows)? The drag-and-drop interface makes it very easy to use, and the possibilities are endless. Today, we’ll review the basics of setting up a Login Flow and some use cases that you can set up in just a few hours!

Setup

If you’ve used Visual Workflow in the past, you know that it’s one of Salesforce’s great declarative automation tools (if not, check out the Trailhead module). While building a Flow can take some extensive trial and error, the breadth of potential is worth it. As we go through each use case, we’ll discuss one possible design for the solution. Please note that this might not be the only way to accomplish these goals.

Use Case 1: Display a message to Users – We’re Changing Our Domain

This is an excellent example to follow last week’s post on implementing My Domain. As part of the implementation strategy we outlined, we strongly recommend a thorough communication plan. One way to do this is to display a message through a Login Flow. For this example, let’s say that we want to show this message only when the Last Login is greater than 30 days ago.

To start, we’ll use a Record Lookup block to find the Last Login date for the user. In a Login Flow, we can use a formula field to access information on the running user with the {$User.APINameofField} notation. We can query the Last Login of the user in one block (below) and assign it to a variable.

lastLoginQueryBlockWe can then use a Decision block to set the criteria for behavior. We can set a parameter for UserLastLogin (our variable for the LastLoginDate of the running user) before 30 days ago, which becomes our defined outcome. Our last block will be a screen that will contain our message to users. When we connect the decision to the screen block, we’ll choose our defined outcome only; this way, when our users don’t meet the criteria, they will escape the Flow and have a normal login experience.

When we’ve finished building and activating our Flow, navigate to the Login Flows page in Salesforce under the Setup menu. You’ll then define the Flow that will be run for a specific Profile. One Flow can be assigned to multiple Profiles, but each Profile can have only one assigned Login Flow. Check out your slick finished product – now you know that your users will see the notification when they log in.

loginFlowFinishedProduct

Use Case 2: Setting Finish Location – Check on Your Oldest Open Opportunity

Our second use case will help point users to a specific page or record in Salesforce. This could be used to direct users to a Visualforce Page or record. As an example, we will have users land on the Opportunity that was edited the longest time ago and is still open.

Our first step will be to query all open Opportunities where the OwnerID is the RunningUserID, and sort them in ascending order by LastModifiedDate. We’ll assign the Record Id to a variable called OppID and create a formula of type Text called FinishFormula: “/”&{!OppID}. Using an Assignment block, we will create a variable called LoginFlow_FinishLocation and set it to the FinishFormula. Lastly, let’s add a screen block to let the users know that they’ll be directed to their oldest open Opp. There you have it – an easy way to drive your users to update Opportunities before they go stale!

 

These are just a few use cases for Login Flows. While these are on the simple side, you can add more logic to give your users the best experience possible. By directing users to what they need most and keeping them informed, you’ll be giving them everything they need to succeed. You’ll be a hero!

If you’re interested in Login Flows, we’ll be publishing more use cases in a later post. Thanks for reading! Have another topic you’d like to see in the future? Send us a tweet! @BeardforceTyler  

How to Implement Lightning Experience

Lightning Experience… (cue thunder sound effects) … Sounds frightening, doesn’t it? Changing the way your users interact with Salesforce AND the way you fulfill your Admin responsibilities?

We’re here to tell you that it doesn’t have to be a daunting task. While making the switch to Lightning is certainly an endeavor and involves some planning, you will be successful if you develop an organized plan. Today, we’ll present a general implementation plan that was the foundation of our implementation plans. Together, we’ll walk through each step and at the end of the post you’ll have a good start on your own implementation plan.

Enough exposition; bring on the Lightning! Before you continue on, make sure to complete the Migrate to Lightning Experience Trailhead Trail and download our Lightning Implementation Plan Template. While this is certainly not an extensive plan, it will get you on your way to bringing the awesome new features of Lightning to your users. Another tool that we’ll reference here is the Customer Enablement Pack provided by Salesforce. The project plan included is what we used to create our implementation plan; we have built it out a bit, but you’ll see some of the overlap.

Assemble Your Team

Each organization is unique in its structure, so there’s no “magic team” that will be best for everyone. We recommend representation from your admins, developers, and IT Support, and the owner of the tool in IT and in the Business. Some of these may be the same person, and that’s okay. If you happen to be the one person for all of these positions, create a team that makes sense for your organization. You’ll need a team who can help advocate for this change with your users.

Step 1: Educate Yourself

The first step on the path to Lightning is to learn about the changes and educate your team. The Trailhead Trails are a great foundation for your learning. Since they’re made by Salesforce, you know the information is correct. If you’re a Premier customer, there’s a Lightning Accelerator that you can utilize as well. Once you’ve finished learning from Salesforce, you’ll want to grab the two main tools that you’ll need for the rest of your implementation process: the Lightning Readiness Report and the Lightning Roadmap. The Readiness Report is available in the Lightning Experience section on the left sidebar under Setup. When you run this, the Salesforce sends you a diagnostic report on how ready your org is to move to Lightning, and lists the items in your org that are not quite ready for Lightning Experience. The Lightning Roadmap is Salesforce’s list of when features should be available in Lightning Experience (Safe Harbor, of course!).

With those items in hand, let’s move on to…

 Step 2: Identify Changes

In this step, you’ll look at each section of the Readiness Report and identify what needs to change in your org to maintain functionality in Lightning Experience. This is a great reflective process, and can help you clear out junk. “THAT page layout still exists? For a third-party app we stopped using in 2011?!” Yep, we can personally verify that this happens. It’s a great opportunity for some spring cleaning.

After you review the Readiness Report in detail, conduct a gap analysis where you identify every change that needs to happen in order to roll out Lightning. We’ll define the details in…

Step 3: Manage Changes

In this step, you’ll start by defining whether your changes are declarative (settings, point-and-click development) or programmatic (code-related changes) and assign them to the appropriate person to complete – in your Sandbox, of course! You’ll also want to do a clean refresh of your sandbox, enable Lightning Experience there, update all third-party apps, and turn on and configure MyDomain. This will help you to start with the best data and configurations from production.

Step 4: Build Out Your Team

“Well I’m the Salesforce Admin, so of course you should listen to everything I say just because I said it” will probably not get your change very far in your company. You need to show people how awesome this tool is, and show that this change is good! You will especially need the buy-in of key stakeholders in your tool, because this change is drastically different for users. When users see something completely different, they will likely be very confused. Their management will hopefully tell them how awesome this change is and all of the great features that come along with it. There’s a sample slide deck for this demo in the Customer Enablement Pack mentioned above.

When your executive sponsor and project team have decided to move on with the implementation, it’s time to put on our thinking caps to…

Step 5: Develop Your Strategy

Lots of work to do in this step…  Apologies in advance; lots of words coming at you.

In this step, the overall goal is to form your strategy for going live. There are countless ways to do this, and you’ll need to pick a solution that’s best for your company. One way to start is actually at the end: how will our users be activated? Will you turn all profiles on at the same time? Just a few? Will you use permission sets to enable users for Lightning (hint: we like this strategy)? Let’s walk through a scenario (from the end):

  1. Users are activated in groups based on when they are trained
  2. Users attend a training
  3. Users receive documentation about the change
  4. Pilot users are activated
  5. Pilot users are trained
  6. Pilot users receive documentation about the change

You can see a pattern here: identify a group, tell them about the change, walk through the change with them, enable the change.

  • Identify a group: pick what makes sense for your org. If you have sales teams, you could enable a team at a time. Make sure to include your support in this decision as well; they’ll need to know who and when will be enabled. If you are the support, then you’re already a step ahead.
  • Tell them about the change: figure out how to best market the switch to Lightning. Change can be hard, but in this case, it’s a great thing. Lean on the new functionality in this material. Make sure the users know that you will do what you can to guide them through this process so they don’t lose valuable time at work looking for features they had previously.
  • Walk through the change: train your users. We definitely recommend a walkthrough of the new tool with users. If you can, record it and post it to Chatter. That way everyone will have the information and can watch the walkthrough again if they forget. If possible, keep the video to about 5 minutes (or less). We recommend taking each of our business units and watching them use the tool so you can see which buttons, etc. are important to them. In your training, you can have Salesforce Classic in one window and Lightning Experience in the other, showing where something is in the Classic view, and then where the feature is in Lightning. It will ease nerves to know where everything is.
  • Enable the change: flip that switch! Either choose a profile-based rollout strategy or a permission set-based strategy. Depending on the size of your company, one of these may make more sense than the other.

You’ll want to talk about how you’ll measure your success. Do you have a goal date by which you’d like your users activated? A certain adoption rate that you’d like to hit? Write these down so you can measure them later.

Now let’s talk about a pilot group. If you have a group that is especially eager to be your first group through the process and is of a manageable size, you’ve got your pilot group. Otherwise, work with your stakeholders to find a group that isn’t huge that is willing to provide you feedback to make sure your overall strategy will work.

Your power users are the folks in each business unit that will help lead change. They can help train users and provide any feedback to you after you go live. Take volunteers if you can, and again be sure that they are willing to be a positive influencer with this change and provide meaningful feedback.

You’ll also need a test plan. Essentially, you’ll need to ask every business unit how they use the tool and run an appropriate number of tests for each feature. Make sure to include any integrations into and out of Salesforce (especially those that we might forget about because they are scheduled jobs that run automatically). Complete this with your power users (and/or pilot group) as User Acceptance Testing and make any necessary changes.

Lastly, make the changes that you defined in step 3. PHEW. We made it through the longest step.

Step 6: Execute Your Strategy

Now it gets exciting! YOU GET TO ENABLE LIGHTNING! It seems scary, but it’s actually underwhelming. No, Lightning will not actually emit from your computer. Now that we’re enabled, we can start rolling it out. Starting with your pilot group, take them through your educational material and training, then enable Lightning for them. Next, go through the same process with your power users. About a week after you’ve gone through these iterations, reach out to the users you’ve activated. What can they tell you about going live? Was anything missed? Was the training sufficient? Make any changes based on the feedback and get ready to…

Step 7: Flip the Switch!

This is the easiest (but not necessarily the shortest) step: iterate through your training/activation plan.

Step 8: Measure Success, Monitor Health

In this step, you’ll want to refer back to your measures for success (or KPIs if you prefer that term). How successful were you? Can you identify any additional changes that should be made? Are users logging in? Are they using Lightning?

Engage with your business users with a survey or focus group, and take their suggestions. Your power users can help identify potential pain points as well. Meet with them regularly for a while to make sure all is still going well.

To wrap it all up, write up a report of your project for your executive sponsor to share with other parts of your company. Very importantly: call out your team for their hard work. You all deserve praise for pulling this off and it’s great to be recognized.


Wow… YOU DID IT! Congratulations. Even more if you made it to the end of this post. We hope this helps you get a start on your Lightning journey. And we want to hear from you! How do you like our plan? Tweet @BeardforceTyler if you have a topic you’d like to see on our blog. Thanks for reading!