Choices in their simplest form allow a user to select only one of a number of choices. The Cloud Flow Designer provides two flavors of this: Radio Buttons and Dropdown Lists. Both are available as a Choice field in the Screen element.

But don’t let this basic definition fool you. When you know more about choices, you’ll soon realize that you can do a lot with it. Here are some of the lesser known aspects of choices in the Cloud Flow Designer.

Global Choices

With the Spring ’12 release, choices have been made global to the flow. Once you define a choice you can reuse it in any Screen element within the flow. This is really handy when building a survey, for example, using the Cloud Flow Designer. It’s very common to provide the user with a Yes/No choice or a question with choices such as Strongly Agree, Agree, Neutral, Disagree and Strongly Disagree. With global choices, this becomes a breeze, where you can define it once and use it in any Screen element.

Choices have “Values”

Choices in flows have a split personality much like Dr. Jekyll and Mr. Hyde. Here’s what I mean: When choices display on the screen – in the Display Text field or in Text Templates etc – its “Label” value is used. However, when the choice is used in any computations or calculations such as formulas or assignments, used to create/update records in Salesforce, or used as inputs to Apex plug-ins, the “Stored Value” is used. This is the reason each choice has a “Data Type”.

Let’s take a look at the Tip Calculator workbook example to understand this. The flow has 3 choices for the Quality of Service choice field. Notice that the data type is Number. The stored value for each of the choices (Good, Fair, Poor) is 15, 10, and 0 respectively. This means the value of the choice when the user picks “Good” is 15. The calculation of the tip is now so much easier. The formula is just {!BillAmount} * {!QualityOfService} /100 .

Note how you can refer to the screen choice field (QualityOfService) and not the individual choice for the formula. This is important, as the engine will use the appropriate value for display and the appropriate value for calculation of the actual choice selected at runtime.

Note also that the stored value is an optional field on the choice. If you don’t set anything, the value is treated as Null. So, if you pass a screen choice to a Record Create element and the field is expecting a value, you’ll get an error at runtime.

Dynamic Choices – Data Driven Choice

As the name suggests, choices don’t need to be static. You can configure your Screen choice field to get the list of choices stored in Salesforce objects. I personally try to make as many things data-driven as possible, so that I don’t need to go back to the flow to make changes. This makes Dynamic choices one of my favorite features, especially when the new choice doesn’t warrant any new treatment in the flow, such as its own branch to process.
What’s more, dynamic choices let you specify filter criteria so that you aren’t querying every record. You can also chain dynamic choices in 2 different screens where the 2nd choice can be made dependent on the first. For example, I was building a demo for an Auto Insurance Quote and I wanted to get the make and model of the car for the quote. This is a classic use case for Dynamic Choice, because it can pull data from Salesforce objects. I created a dynamic choice for the make and filtered the models for the make in another dynamic choice in a second screen.

No one should have a flow with individual choices for all the makes and all the models of all the cars being insured!

Not every dynamic choice needs to be configured with “real Data”

One of the important notes about flows I emphasize to customers is that a flow is essentially a “client of the API”. This was an eureka moment for me when I was building a contest management app internally and I was looking to build a page with 3 large clickable images which serve as site navigation menu.

Clicking on each image will link the user to a different page. I didn’t want to build the page with Visualforce, as I wanted this to be data-driven. I wanted something which is efficient and can be configured without any sharing or security controls, because I wanted anyone to be able to participate in the contest. I almost created a custom object, but I realized I could use custom settings instead. The data is cached, doesn’t vary by user, and is valid throughout the organization. Since custom settings is part of the API, it just appears like any other object in the dynamic choice resource element. Problem solved!

Hope this gives a little bit more insight into the exciting world of choices in flows! Until next time, over and out…

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS