Let the Salesforce Requests Flow

My Goals

This post is going to be an overview of what my flow does. This isn’t a “How-To build a flow” post. Please let me know in the comments if there anything you want to see more in detail or want to more of a “How-To” post!

I wanted to make sure I met the following objectives:

• Create a case, capturing the User’s name (Contact) and setting it to my company’s account record
• Let the user select the Type of project they are requesting
• Guide the user to provide different information dependent upon the project
• Assign new Cases to my Queue
• Assign cases to my Record Type
• Be accessible within Salesforce
• Be Accessible outside of Salesforce (bonus)

Based on that list I knew my flow needed to have the following setup:

• Look up of the User to find their contact record (We create a contact record for each user. The contact has a lookup to their user record)
• Look up the Account ID for the company account record (using a sandbox so can’t hardcode!)
• A screen to ask the user what type of project they’re requesting
• A Decision Element to take the user to sub-project screens based on their selection
• Separate screens for each type of project I need specific information for
• Create case Element
• Confirmation Screen to let the user know their case number

The Whole Flow

Here’s the whole flow. Don’t panic! I know it looks like a lot, but it really isn’t bad once you break it down. Your flow could be much more simple than mine depending on your needs.

Preparing ForThe User

Preparing for the User

Most of my flow occurs before the user even sees their first input screen. You can actually skip 7 of these elements if all people submitting requests are Salesforce users and they also already have contacts. 7 of my elements, the right hand side portions, are there to support people submitting a case without being logged into Salesforce.

Let’s start with the assumption you’re a Salesforce User. Before you see a screen I need to know a series of information:

• Your Name
• Your Contact ID
• The Case Record Type to be assigned
• The Queue user that will be the owner
• The AccountID to associate the case
  The first 4 elements starting with the “Record Lookup, Lookup User” going down do exactly this. Based on the user submitting the request, I grab the name of the user. Then I look up the contact for that user and finally get the Case Record Type ID and Queue ID. That’s it. Now I’m ready to go.

The 7 other elements are there for non-salesforce users. Here, I check to see you’re an External User. If you are an external user, I prompt you for your Name and Email address. Then I search for your contact and if it doesn’t exist I create one. After that setup I pass you back to the element that looks for the Case Record Type ID and on our merry way we go. More about making this available to non-salesforce users at the bottom of this post.

User Inputs

For Salesforce users, the first screen will ask what team you belong to and what Project you’re requesting. Both of these are single choice field aka a pick list.

The next element is a decision which takes you to a new screen based on the project type selected. The next section is a Record Create element, one for every different project type. This is one area where I may go back change this to a single record create. My original intention was to set a rich text field on the case with the various pieces of information collected. Since those screen inputs are different each screen, I thought I needed individual elements to create the case.

Not so! I discovered a beautiful thing called a “Text template. A text template is basically a variable that you can concatenate multiple other variables and screen inputs into one gorgeous text block. It’s also Rich Text enabled so you can bold text or just do straight HTML. This means you can have multiple Text Templates, one for each project type and only 1 Record Create element. That’ll remove 4 elements from this flow which would be nice.

The Finish

So far we’ve gathered information about the requesting user and information about the project. We just created the case. The finale part of this flow is to provide the user with a confirmation. This is a screen with just output text. I provide them the case number and say thank you for their request.

The other part of this flow helps set the redirect for the user. A Salesforce user will be redirected to the case they just submitted. They can then add case comments or attach files if needed. A non-Salesforce user will be taken to the start of the flow.

Those Non-Salesforce Users

I made this available to non-Salesforce users by making my Visualforce page with the embedded flow available in Force.com Sites. This posed a few interesting challenges. First, users outside of Salesforce need to be able to have Create/Read access on the Contact and Case objects. I have a private sharing model in this Organization so I also needed a sharing rule to give them access to the Account record for our company.

Making the actual flow available after that was easy. I added the Visualforce page to my existing site and shared the link. It is unauthenticated so I do run the risk of people who leave the company submitting a case and potentially other non-employees. I’m the primary person that see these cases so it’s simply to delete those records. Plus, I can always disable the public access if I need to.

Final Notes

A few things I changed from the details above.

• I removed the Case Record Type ID and opted to have that set by workflow rule. I decided I only wanted users to be able to create my request cases through the flow. I didn’t want them creating “New Case.” This meant I couldn’t assign my record type to the users. Flow only has access to the same setup as the user using it. So I had to be content with them creating a case with the default record type and then updating it via workflow rule.
• I also added a link to the visualforce page as a Home Page sidebar component. This way it’s available on almost every page within Salesforce
• For the project type “End User Support” in addition to providing the fields I want, I also give them the link to our Salesforce Support Chatter group

I’m in the early process of rolling this out to people. Feedback from users have been very positive so far. I like this option since it provides me an easy declarative method for adding additional project types in the future. It was also very easy to setup and get working.

Want to see what it looks like? Of course you do! Here’s is a short video. I didn’t go through all the trees, but it does give you an idea of what you can do with the Flow. There’s also no sound. I apologize for that, but I couldn’t get my free recording software to encode the audio properly. http://goo.gl/vmjj7K

A Note From The Editor

A little secret about WizardNews posts. I hate writing Post Titles. I struggle with trying to write titles that are informative, accurate, and grab your attention. One of the more difficult parts is not to interject my sense of humor into the title – too much. For example, alternative titles for today’s post included:

• Why Salesforce Admins should just go with the Flow
• Flowing with the projects
• Setup your own Salesforce Request with Flow

What other titles can you come up with for this week’s blog post?

Let me know in the comments!