The Journey Begins

Thanks for joining me!

Good company in a journey makes the way seem shorter. — Izaak Walton

post

New Flow Screen Components on the AppExchange: Swipey and Flow Magic

Some excellent screen components are starting to get published as Salesforce Labs packages on the new Flow Solutions section of AppExchange. These require no code at all.

Swipey is essentially a Multi-Select Picklist control with a fun, visual swipe-left, swipe-right usage model:


Flow Magic provides a way to create picklists that use images and icons. It’s a Visual Picker builder:


Service Agent Script provides a high-visibility talking script component:


Using Flow with Chat, Bots and SMS via Twilio and Authy

Never have we crammed so many different forms of awesome into one solution. Special guest appearance by Custom Metadata Types.

Credit to Kamlesh Patel who actually built this demonstration and the components in it.

Check out the video: https://youtu.be/G5q6jiBkqoI



How to Build a Flow Action with Apex

The other day I built a flow action that generates random numbers. While doing it, I recorded the process, because we don’t have a lot of tutorial material on how you can turn a chunk of useful Apex code into a nice, declarative flow action.

Here it is.

For a general introduction to the invocable action interface, check this out.


Understanding Invocable Actions

Easy Random Numbers Come To Flow

So I was reading this thread that mentioned random numbers, and then I read this great post about building a Blackjack game out of flow, and the Monty Python-caliber dry humor (which may or may not be intentional; I haven’t figured that out yet) about the complicated math necessary to generate pseudo-randomness. And then I thought about how easy it is over in Apex-land to generate random numbers, so I built a Flow Action you can install into your org that takes two values and generates a true random number in that range.

Check it out here.

Guest Post: Duke and Luke’s Blackjack-in-Flow

While browsing reports of flow sessions at Dreamforce, I came across two guys claiming to implement an Entire Heckin’ Blackjack inside of Flow. This is My Kind of Dreamforce Session, but I wasn’t able to make it because they keep Product Managers very busy at Dreamforce. As of this moment I’m still waiting for the video to get posted, but in the meantime I asked them to write a blog post. As you can see, this flow involves everything: Steps, Debugger, Lightning Component, Formulas. It’s really impressive, and the blog post is presented here.

============

Architect: Sean Dukes
Coder: Luke Kozakewycz

By Sean Duke

It all started at a Salesforce user group. I was doing a presentation on Lightning Flow. I’d used a ‘Hello World’ Lightning component and showed how you could change the greeting based on the region of the person. It went down pretty well, but it was hardly the rich user experience you read about.

Fast forward a few weeks and for some reason I had the idea that Blackjack would be a great visual use case. I sketched out a basic design and it seemed like it ought to work, so I submitted the idea as a Dreamforce talk. I didn’t expect things to go any further, so it was something of a surprise when a few weeks later, the email came through. “Your idea has been accepted, can you run us through your slides next week?”

“Yes, of course.” There followed an interesting few days where we put some slides together and tried to turn those early sketches into something that at least proved that what we wanted to do was possible.

“The first thought that struck me was that I’d never played Blackjack.”

The first thought that struck me was that I’d never played Blackjack. There could be experts in the room. I needed to truly understand how to play the game, so I wouldn’t get found out. I hunted around the internet and interviewed a couple of people who had played. My initial ideas weren’t far off, but, now that I had my user stories, it was interesting how much like a real project this was becoming.

In Blackjack, you typically have more than one deck of cards and they’re not shuffled between every hand. But they are shuffled. The first job was to get those cards and shuffle them. Salesforce doesn’t have a random number function, which would have made our life easy, so we had to come up with another way.

If you think about it, when you shuffle cards it isn’t random. The order they start in determines the order they end up in. We didn’t need random, we just needed unpredictable. So how do you do that?

There are in fact several ways you could do this. This is mine …

The solution we came up with was to use two objects. The first object was the base deck. This contained the 52 cards, with their value, an image url, the name and whether the card was an ace or not. We also assigned each card a different five-digit prime number.

For the first shuffle, we looped through the base deck and added two of each card to a new sObject Collection. As we did that, we calculated a number we call the seed.

The formula was pretty simple.

The formula was pretty simple. Multiply one thousand plus the time the user was created in hundredths of a second by the card prime number and then by a second five-digit prime number. This gives you a number of between twelve and fourteen digits. We then take the right hand seven digits which is our first unpredictable number.

VALUE(RIGHT(TEXT([Card prime number]*([Time Created]+1000)*[Prime number 1]),7))

When we add the second card, we use a different prime number. We now have 104 cards in an sObject collection with 104 unpredictable seed numbers and we save this to a second object called Card Deck that has a lookup to the user. If we sort by this, then each card deck will have a different card order for each player unless they created their accounts at precisely the same second.

We don’t stop there.

We don’t stop there.We use a second field called the shuffle order. This is a formula field that multiplies the seed by a ten digit prime number and by the record number of the card in the card deck (a sequential number) and then we take the middle seven digits. This is the field we actually sort by. Even if two players started at exactly the same time, their shuffle orders would be radically different.

Shuffling again is simple. All we do is copy the shuffle order to the seed field and this creates a new shuffle order. It works really nicely.

It’s easy and satisfying to test this. The first thing to do is create a list view that shows the user’s cards.

Then you go to the shuffle flow — we have a separate flow because we re-use it in several places.

Now you click the debug button and enter in the user ID, which is the only input parameter required by the flow and click Run.

It’s worth noting that this debug method actually does run and changes data. It’s not something you want to be doing in your production org with an untested flow! For our purposes though, it’s great. Click refresh and you can see the result.

So shuffling was a good start and relatively straightforward. Now for the game itself. This was definitely the heavy thinking part. The breakthrough came when we started to look at the journey of each individual card.

We load the shuffled deck into an sObject Collection and then follow each card around. We use a series of variables to record what is happening with the player and the dealer and then we make decisions based on the value of those variables.

It took a while, but this is what we ended up with.

Break this down and the first part of the flow is all about getting ready. The right hand loop represents the playing of a single hand and the left hand loop runs when that hand is over and we get ready to play the next one. Simple 🙂 In all we ended up with 34 elements in the flow and four of those are to stop people cheating!

We should probably confess at this point that we decided splits, doubling and insurance were out of scope for our project. I have no doubt we could add those things in now.

A couple of things we noticed as we went along. Firstly, we were really diligent about creating descriptions on every flow element as a first step. Writing in long hand exactly what we expected to happen at each stage made completing each element much easier and the whole thing was easier to debug. The other thing that was interesting, was that the more efficient and the more correct our flow became, the fewer elements we had and the more elegant the flow itself appeared. I’m particularly proud of the fact that in the whole flow, we only ended up with one crossing connector and though I’ve tried, I can’t see a way to get rid of it. It will be interesting to see what this looks like when we put it in the new Flow Builder.

One thing that helped to keep the flow manageable was using formulas. For example, we have an assignment step where we work out the outcome of the game when the dealer has finished playing. We could have done this with a decision element and five assignments, but we were able to achieve the same thing with one assignment and a formula. Our assignment step sets the value of the GameOutcome variable to a formula result. This trick really cut down on complexity.

We tested our game as we were building it using a variation on that original ‘Hello World’ component. We had a view showing us the player’s card deck and then put our component onto a page, then we could compare the two side by side and make sure the game was behaving as we expected. This was crude and we didn’t have hit and stand buttons, but it was very useful.

At this point we had a working game and my coding skills had reached their limit. It was time to call in a professional! The Lightning component we built looks great, but it does remarkably little work. The screen element passes various values into the flow so that we know what we want to display. It has a timer, so you can see the cards being dealt out and it does look pretty, but that’s effectively it.

The only time the Lightning component changes a value is when the player hits stand. There’s an attribute called DealToPlayer. This will be true if it’s the player’s turn and if the player hits ‘Stand’ then this changes to false and is passed back to the flow. The flow does the rest.

Now all we needed to do was drag our flow onto the Lightning community home page (or in this case onto a Contact page for testing) and that was that.

We had our game and we could and did take it to Dreamforce. We even managed to get the whole audience playing in our special community and we had prizes, including for the fastest loser! Overall, it was great fun and a hugely interesting learning experience. If you want to find out more then, when the recording comes out, you should watch it.

Architect: Sean Dukes

Coder: Luke Kozakewycz

We both worked on bits of all of it.

© Sean Dukes 2018

The Horizontal Rule Flow Screen Component

Note: this is not an official Salesforce product and is not supported by Salesforce.

Built a simple component recently that provides flow screens with this simplest of html entities. The wrinkle is that it’s styleable, providing an effective, colorful section header.

Check out the video.



September Content Report — Flow and Components

In which we draw your attention to great things being written:

Delete Records Using Process Builder

Using the new Page Reference mechanic to pass query parameters from URLs into Lightning Components

A great tutorial on Flow Stages by Jennifer Lee

Another great tutorial by Jennifer Lee on Local Flow Actions

Arnab’s introductory blog post covering the new Flow Builder

Bob Buzzard on Background Utility Items

Doug Ayers Deep, Useful, and Interesting Material on Calling REST from a Lightning Component , specifically his new library.

Know about a good blog post covering Flow, Components and Salesforce AppDev? Let us know about it at YesIllDoYourWorkForYou@edelstein.org

Salesforce Lightning Flow — Using Advanced SOQL

It’s surprisingly straightforward to add a complex SOQL query to your Lightning Flow.

The process involves creating a simple Apex class that carries out your query, and then ensuring that class shows up in flow as a declarative building block that can be dragged into your flow.

The key technology that enables you to publish your apex into flows is has the name Invocable Actions. Our (Salesforce’s) documentation on this technology is inconsistent and we’re working on improving it. The most important page is actually somewhat buried. This page is important because it provides a code sample for the best apex design pattern for invocable actions.

Here’s an example of an apex class I wrote to carry out a single, complex SOQL query:

https://gist.github.com/alexed1/2681d302fc0b2bb178fe8e5436c97c12

Note that in this pattern, I create a Requests class to store the inputs that my SOQL query will need and a Results class to define the values that my flow action will return to the flow.


In my example, I carry out my SOQL query in two parts. I first retrieve the name of the user and then retrieve a count of all cases associated with that user name.


I then create a Result instance and pack it with the important values returned with my queries:


Finally, I create a List container and add my Result to it. I use a List even though I know I’ll only have a single Result. That’s just part of how the Invocable Actions interface works: each action is expected to return a List (this makes it possible for the interface to support collections and single value responses with a single method).


Because I’ve annotated a method in my AssessCustomerStatus class with @invocableMethod, this functionality will now appear in flow as a declarative building block:


Dragging this flow action onto your canvas allows you to map upstream values to its inputs, and make use of its return values:


If you can create advanced SOQL queries, you‘re enough of salesforce dev to expose them as declarative flow actions. This opens a lot of new applications up to you.