Finally! A Use for Invocable Processes For Our Org….

There was a lot of excitement in the Process Builder community when invocable process were released last year. I attended the webinars, read the release notes, checked out the blogs with the hope of being ready to streamline existing processes or build better ones later with less effort. Tick, tick, tick….many months later and I still hadn’t found that use case that worked for us – until two weeks ago.

A very engaged set of users bent on improving the system presented some ideas they had formulated. This group is great because they really do want to improve how they use Salesforce and if the idea is extendable to other units all the better. It’s that innovative group that every admin fears when the email pops up but at the same time the one we love the most because they are as engaged as we are. Ok – enough flattery for them – on to one of the ideas that started all of this.

Can a Salesforce trigger change the “Close Date” for us?

Ok so let’s break that down a little more –

Current State

  1. The Sales team selects today’s date from the calendar or manually types in the Close Date when an Opportunity is changing to a closed stage (Lost/Won/Cancelled). Can it just update for us so we don’t have to enter it?
  2. Saving the opportunity triggers a validation rule: Close Date <> TODAY (). The incorrect date results in an error message stating “You have closed this opportunity but the date provided is in the past or future. Please enter today’s date.”

Request The Sales team would like the Close Date to populate with today’s date to eliminate a) small amount of data entry and b) eliminate the chances of encountering the validation error should that date be incorrect.

Ideal State The Close Date will auto-populate with today’s date upon Save.

Challenge The business allows users with special permissions to update CLOSED records. Implementing a Process Builder that adds the requested date will fail for most users because the edit of the date would occur after the record is flagged as IS CLOSED.

So there you have it – a need to update the record with the Closed Date using Process Builder but there is that pesky validation rule waiting in the background with the dreaded process flow error.

This is where invocable processes, a solution from a knowledge article and an update process converged for an All Clicks, No Code solution!

Part 1 – Bypass the Validation Rule

I looked on Google, of course, for a solution some time ago and did find ideas but they all used Apex or flows. Apex, beyond what I’ve done on Trailhead, is out of my wheelhouse and I have attempted flows which was not an overwhelming success.  A renewed, last-ditch search effort yielded a new result scaring up a knowledge article from Salesforce titled Bypass Validation Rules for Process Builder. What Luck! The article walks through two scenarios and offers two workarounds. The workaround implemented in this case is the second.

The use case in the article centers on Accounts and the automatic updating of related Contact mailing addresses.

“On Account you have a multi-select picklist and you use Process Builder to update the same field on the related Contacts. Now if some Contacts do not have a valid Mailing Address, you will get an “ALL_OR_NONE_OPERATION_ROLLED_BACK” error.”

The solution was:

“Implement a field which allows bypassing validation rules for Processes, on Account have a checkbox field BypassValidationForProcessBuilder__c, default unchecked, not shown on the Page Layout.”

Adjust the Validation Rule to:

AND( NOT(Account.BypassValidationForProcessBuilder__c) ,

OR(

ISBLANK( MailingStreet ),

ISBLANK( MailingCity ),

ISBLANK( MailingCountry )))

 In your Process:

  1. In the immediate action block, first use a record update for the concerned Account record to set our Bypass field to TRUE.
  2. Within the same immediate action block, you can now have an action to update the related Contacts, use as many actions as needed.
  3. Then at the end have another update action to set the Bypass field back to FALSE.

Within one immediate action block, the actions are done in order and separately.

That’s great…. if I was trying to solve the problem of Account mailing address changes cascading to Contacts but this workaround could be readily adapted to suit the addition of the Close Date for users. Swapping out the Contact Object for the Opportunity Object is all you need to accomplish this. Let’s build this reusable Bypass functionality out step by step and then apply it to update the Close Date on the Opportunity.

Create the Field – The first thing we are going to do is create the field that will be referred to in the Bypass processes and validation rules.

  1. Go to Set-up>Customize>Accounts>Fields
  2. Click NEW>Checkbox>Next
  3. Name the field. How you name it is up to you but having Bypass in the name will help identify it later. I went with BypassValidationRule to shorten up the Salesforce name but keep it obvious.
  4. Specify Visibility and Page View settings
    1. For visibility, I set that to admin only and did not add it to page views. Note – In the sandbox, I did add it to the page views while testing.

Now we build the to invocable PB processes. First we will create the Bypass = Yes process.

Create the Processes – This first process will set our Checkbox to True.

  1. Go to Set-up>Create>Workflows and Approvals>Process Builder (or type process builder in the Quick find to get there faster)
  2. Click NEW and Name the process. I named mine Bypass Validation Rules YES. YES or True in the names makes it easy to know which one to us later.
  3. Select – The process starts when – It’s invoked by another process and click Save
    1. You will notice on the next screen the process name has (invocable) at the end
  4. Pick Account as the OBJECT
  5. Criteria = No Criteria
  6. Click + to add an Immediate Action:
    1. Action Type = Update Record
    2. Action Name = Set Bypass to Yes
    3. Record Type = Select the Account record that started your process
    4. Criteria for Updating Records = No criteria—just update the records!
    5. Set new field values for the records you update
      1. Field = BypassValidationRule (add your field’s name; this is mine)
      2. Type = Boolean
      3. Value = True
    6. Save and Activate

Now, create the second flow, Bypass = No This process will set our Checkbox to False.

While in your newly created YES process, click Clone and select “A New Process”.

  1. Name the process- I named mine Bypass Validation Rules NO.
  2. Click on the Immediate Action – Set Bypass to Yes
  3. Change the name to Set Bypass to No
  4. Change the Value to = False
  5. Save and Activate

Now we have our bypass field and processes all set-up. Time to apply them to a process and update our Close Date without triggering the validation rule!

Bypass PB 1

Create the Process – This is where we set the close date.

  1. Go to Set-up>Create>Workflows and Approvals>Process Builder (or type process builder in the Quick find to get there faster)
  2. Click NEW and Name the process. I named mine GLOBAL – Autofill Close Date on Close Opps. Global is the designation used when something applies to all business units in our org.
  3. Select The process starts when – a record changes and click Save
  4. Pick Opportunity as the OBJECT
  5. Criteria – Give your criteria node a name
    1. In this case, you’ll see that we are applying this to records based on stages, not ISCLOSED. This was done based on other articles stating that using ISCLOSED is not the best practice and that we also only need to trigger this one time when the stage changes to one that is closed. The stages will vary based on your stages and org. In our case, once it’s closed; it stays closed. On to my criteria:
Field Operator Type Value
StageName IsChanged Picklist True
StageName Equals Picklist Closed Cancelled
StageName Equals Picklist Closed Lost
StageName Equals Picklist Closed Won
StageName Equals Picklist Closed No Bid
  1. Customize the logic – 1 AND (2 OR 3 OR 4 OR 5)
  2. Immediate Action 1:
    1. Action Type = Processes
    2. Action Name = Set Bypass to Yes
    3. Process = Select the Bypass Validation Rules YES process
    4. Set Process Variable
      1. Type = Reference
      2. Value = Account ID
        1. Note – Do not pick the Account ID> option. This will not work. Scroll down to the Account ID without the ” >”
      3. Click Save
    5. Immediate Action 2:
      1. Action Type = Update Record
      2. Action Name = ADD TODAY
      3. Criteria for Updating Records = No criteria—just update the records!
      4. Set new field values for the records you update
        1. Field = CloseDate
        2. Type = Formula
        3. Value = TODAY()
      5. Click Save
  1. Immediate Action 3:
    1. Action Type = Processes
    2. Action Name = Set Bypass to Yes
    3. Process = Select the Bypass Validation Rules No process
    4. Set Process Variable
      1. Type = Reference
      2. Value = Account ID
        1. Note – Do not pick the Account ID> option. This will not work. Scroll down to the Account ID without the “>”
      3. Click Save
    5. Go to a separate tab or window and update any validation rules that need to be bypassed with the addition of the NOT(Account.BypassValidationForProcessBuilder__c) edited to suit your field name.
    6. Now ACTIVATE this process!

Bypass PB 2

 So what about those “other things” this could be applied to that made the invocable useful right away?

Using the Bypass processes allowed us to add a name to a record which is only done at time of closure. This stopped the triggering of a delayed action process builder error email that served as a prompt to go update the record manually. This occurred when the user closing the record lacked the permissions to edit after close. It was a minor improvement to the data timeliness and took a bit of work off the administrator. Not earth shattering but hey, a win is a win.

Earlier I said “That’s great…. if I was trying to solve the problem of Account mailing address changes cascading to Contacts”. Well, the bypass is getting added to that process and related validation rules. We rarely see that error anymore but it will be even nicer to never have a user or myself see it again!

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s