Let’s say you’re an investment firm selling certain ‘strategies’ or products and you need a seamless transition from the sales cycle to the operations team.
Here’s the use case:
Every time a sales rep has a ‘Closed Won’ Opportunity a ‘Product Commitment’ (custom object) record needs to be created associated that Account along with a Product Commitment detail (another custom object) record. The trick is that there can only be one type of Product Commitment per Account. Also, the operations team needs to know when the capital (or funds) was committed with the added complexity of several possible opportunities committing to the same product.
In other words, once a ‘strategy’ is sold you need a ‘Product Commitment’ record. If, at a later time, the client wants to commit more capital (more opportunities), that record (and the related detail record) needs to be updated.
Here’s a pseudo-entity model to help understand the process:
Why Process Builder AND an auto-launched flow? Process Builder is used to trigger the event, and visual flow prompts a complex business process: we need to go see if the record already exists – if it does – update it – if it doesn’t – create it.
Trigger the event: Process Builder
Create the process by going to Setup | Workflow & Approvals | Process Builder. Create a new process on the Opportunity object when the record is created or edited. Start the process as soon as an Opportunity Stage is set to ‘Closed Won’:
Create your visual flow
The flow will first look at all your records to see if the Product Commitment record already exists on the Account in question. The Process Builder is going to feed visual flow the variables.
Open flow designer by going to Setup | Workflow & Approvals | Flows. Save as an ‘auto-launched’ flow. Find ‘Record Lookup’ and drag it onto your design space.
This ‘Record Lookup’ is looking for the won Opportunity Account, along with the Product Commitment record. If that combination already exists it would spit out the already created Product Commitment record id. If not it will create it.
To create the variables just select the down arrow and ‘new’. It’s a good idea to always start them with something like ‘var_’. This naming convention helps distinguish variables from other types of assets, like constants.
This record look up section is looking through the Product Commitment records to see if that Account has a Commitment record for that Product (Strategy).
Drag the Decision onto the design space to determine the outcomes:
The Resource for this decision is the Record Look up you just created. Did the look up request find anything? True = record exists, False = record does NOT exist.
So far our flow looks like:
For this example, we will add two paths for the outcomes of those decisions.
If the record doesn’t exist, create it using the variables passed by process builder.
You use the created ID to then create child records. The ‘Product Commitment Detail’ records would be created the same way as the Product Commitment records.
Let’s say you need to update child records? For example: your rep changes the amount on an Opportunity. When the rep hits ‘Save’, the child record can be identified and updated. The entire flow would look like:
Now that we have our auto-launched (headless) flow created, Process Builder is used to pull it all together. All the flow variables we created will show up in Process Builder when we choose our auto-launched flow:
Once an Opportunity is Closed Won, this is what is displayed in the Account’s related lists:
The Product Commitment record and its detail would look like:
Use case: Sales rep updates the amount on the original Opportunity.
Result - this flow: All the associated Product Commitment records would update auto-magically[KB4] .
Use case: Client wants to commit more funds to this product.
Result - this flow: Only the ‘Product Commitment Detail’ record is created.
This flow updates records and creates records. The whole process works seamlessly in lightning as well as classic Salesforce.
- Janna Cenko