What salesforce does is simply amazing. They allow a non programmer, like me, to be a developer – or as I like to call myself a Button Click Developer. Since 2002 I’ve been doing things which normally only programmers DBA’s, and web developers could do before. Salesforce has moved the code cliff enabling me to do for others what I couldn’t do for myself during my C++ classes at Cal Poly. This next feature, trigger flows , now in pilot as of Summer 14, is going to make Reno Nevada beach front property.
The first time I heard about the code cliff was at Dreamforce ’13 – from Shannon Hale. The Code Cliff is that which we admins stand on when we’ve realized APEX has to be created. The moving of the cliff are those new features which enable admins to do what developers do. As much as salesforce.com has enabled admins to do over the years we’ve been yet to declaratively create new records while preforming logic and/or lookups to other records; which maybe 10-15% of the time we need to do. When we have such a need, we must engage a developer which is going to take a bit of time and some $$ to write a trigger. In 2009 Salesforce.com acquired Informavores which gave birth to VisualWork Flow in late 2012, which appeared to have some promise on moving the code cliff.
I don’t believe Visualwork Flow ever really took off as many had hoped . I wanted to use it but with some of the limitations and always needing a user intervention to fire the process, this was never really something the business needed . It was ‘nice to have’ if you could get to it, type project, a wizard of sorts, or call scripting. But here comes Trigger Flows, the ability to fire a flow process indirectly based on standard workflow. My current project is working for a financial company underwriting and servicing auto-loans. Some examples of where I can apply this are:
- When a web2case form comes in with a Loan Number in a text field, I could lookup the text field and populate the Loan Lookup field.
- How about when a payment comes in and is on time ? It creates a transaction record for the loyalty program to pickup and award the borrower some points.
- When a member updates their picture award points.
What use to be a developer engagement is now an exercise in building a Flow with a Flow Trigger. Take this simple example of when a member updates their picture and we need to award them some points. To make this work our Loyalty Program requires a record in the Transaction object with fields: Type and Member, with the values of “System , ” and Member Record ID , respectively. From there the system has the logic to do the rest. So how do we do this?
First create a standard workflow on the member object to look at a field called ImageID. When ImageID is filled in, i.e. not Null, we fire the workflow. But what workflow actions do we use ? The new Flow Trigger takes care of it, see screen shot: http://screencast.com/t/A8ebP1nQyyLn. This Flow Trigger has 3 components; Object, Flow, and Flow Parameters. The Object is the primary object to reference used for the field parameters. The Flow is the flow to be used. Flow Parameters are the field mappings between the object and the flow input parameters.
The key to flows are what fields are given to it and what it does with those fields. Taking a look at the Transaction Flow: http://screencast.com/t/5E5fUrgM, you can see it can take 6 fields, however not all required. My Flow Trigger is what does the giving: http://screencast.com/t/3ruQhDfEAUyE. It passing one variable and sets two fields to the transaction record. Therefore the transaction record will be created with the Member Field it receives along with TransactionName = “Profile Update” and Type = “System.” From there the rules of the system take over and does it’s thing. You now have a new record when a member updates their profile picture.
This is a game changer . This is going to be a 7+ on the rector scale and possibly an 8 . Reno Nevada is going to become beach front property. The simple fact I now can create, lookup, and search records is amazing!