Privacy Policy

Privacy Notice

This privacy notice discloses the privacy practices for Unofficial Flow Actions. This privacy notice applies solely to information collected by this website. It will notify you of the following:

  1. What personally identifiable information is collected from you through the website, how it is used and with whom it may be shared.
  2. What choices are available to you regarding the use of your data.
  3. The security procedures in place to protect the misuse of your information.
  4. How you can correct any inaccuracies in the information.

Information Collection, Use, and Sharing 
We are the sole owners of the information collected on this site. We only have access to/collect information that you voluntarily give us via email or other direct contact from you. We will not sell or rent this information to anyone.

We will use your information to respond to you, regarding the reason you contacted us. We will not share your information with any third party outside of our organization, other than as necessary to fulfill your request, e.g. to ship an order.

Unless you ask us not to, we may contact you via email in the future to tell you about specials, new products or services, or changes to this privacy policy.

Your Access to and Control Over Information 
You may opt out of any future contacts from us at any time. You can do the following at any time by contacting us via the email address or phone number given on our website:

  • See what data we have about you, if any.
  • Change/correct any data we have about you.
  • Have us delete any data we have about you.
  • Express any concern you have about our use of your data.

Security 
We take precautions to protect your information. When you submit sensitive information via the website, your information is protected both online and offline.

Wherever we collect sensitive information (such as credit card data), that information is encrypted and transmitted to us in a secure way. You can verify this by looking for a lock icon in the address bar and looking for “https” at the beginning of the address of the Web page.

While we use encryption to protect sensitive information transmitted online, we also protect your information offline. Only employees who need the information to perform a specific job (for example, billing or customer service) are granted access to personally identifiable information. The computers/servers in which we store personally identifiable information are kept in a secure environment.

If you feel that we are not abiding by this privacy policy, you should contact us immediately via email at privacy@edelstein.org .

Flow Actions for Google Apps

This site is the home of Salesforce Flow Actions for Google Sheets. This is not an official Salesforce site or software.

These flow actions make it easy to use Google Sheets and Google Docs with Lightning Flow.

 

 

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.


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.