During this presentation we show two examples of uses cases that prevent users from manually updating records, but allow them to update records through automation fired by logging activities. Both solutions are completely declarative. Use Case #1 Hat-Trick Consulting wants to prevent sales reps from manually editing the Contact Status field. This field should only be updated when the rep has logged an activity to the contact. The type of activity dictates what status to change the record to. We will demonstrate two separate solutions for these similar uses cases, both are all declarative. Solution : To allow for the use case of prohibiting manual editing of the Contact Status field, while allowing related activities to update this field we will use a combination of functions that will include: 1 Validation Rule, 4 Custom fields, 3 Process Builders Use Case #2 Hat-Trick Consulting wants to prevent service reps from manually changing the case status field to “working”. This field should only be updated when the rep has logged a specific activity to the case. Solution: To allow for the use case of prohibiting manually moving the Case Status field to “working”, while allowing related activities to update this field we will use a combination of functions that will include: 1 Validation Rule, 1 Custom field, 1 Process Builder, 1 Flow

1. Bypassing Validations Rules Through
Automation
Aaron Crear

2. #CD19
Salesforce Goals Achieved
Services:
● Administration
● Development
● Training
Aaron Crear
Founder & Principal

3. #CD19
Salesforce Changed my Life!
Recovering Sales Manager
- User since 2009
- Began self-learning to make my job easier
- Became default Salesforce Admin
Rolled the dice in June 2016, accomplishments to date
- Began with Trailhead
- 5 x Salesforce Certified
- Full-time consulting practice with book of clients
- Speaker at Dreamforce, Big Sky Dreamin’, Czech Dreamin’, dreamOle’, Florida Dreamin’
French Touch Dreamin’, Phillyforce, Midwest Dreamin’, Snowforce, Southeast Dreamin’, True
North Dreamin’
- Lowell, MA User Group Leader, Northeast Dreamin’ Co-Organizer
Why am I here?

4. #CD19
Validation rules are a useful method of maintaining data hygiene, orders of
operations and ensuring that users follow the correct work processes.
However, at times they can be a hinderance to being productive. In this
presentation we will show you how to allow users to bypass validation rules
to update records through their activities without allowing them to manually
update records.
Abstract

5. #CD19
Allow user actions to update records, but no manual editing of field.
Hat-Trick Consulting wants to prevent sales reps from manually editing the
Contact Status field. This field should only be updated when the rep has
logged an activity to the contact. The type of activity dictates what status to
change the record to.
Use Case # 1

6. #CD19
Unsuccessful
● Add a validation rule that prevents reps from editing the contact status field
● Make the contact status field read only on the page layout
● Create automation that simply updates the field based on activity creation
Result: Since the user is firing the automation from the record, they must have edit access on the page
layout. Using this method causes an error for the automation, thus preventing them from logging the activity.
Automation also catches on the validation rule if you try to leave the field as editable on the page layout.
First-thought Solutions

7. #CD19
Successful
To allow for the use case of prohibiting manual editing of the Contact
Status field, while allowing related activities to update this field we will use
a combination of functions that will include:
■ 1 Validation Rule
■ 4 Custom fields
■ 3 Process Builders
Actual Solution

8. #CD19
Contact Object
We will add four custom checkbox fields Contact object. These will be used with each of the
three process builders. These fields can be left off the user page layout, however users need
edit access. Leaving them on an admin layout is a good way to test and troubleshoot.
Bypass_Validation__c
Fire_Process_Builder__c
SAL_Task__c
SQL_Task__c
Custom Fields

9. #CD19
Contact Object
We will add a new validation rule on the Contact object that prevents users from
editing the Contact Status field unless the new custom field Bypass Validation
equals true.
Validation Rule

10. #CD19
Set Bypass
This process builder will set the Bypass Validation and either SAL Task or SQL Task on the
Contact record, which essentially disables the validation rule. You can choose your own
criteria, but this would run on either the Task, Event or both.
Process Builder #1

11. #CD19
Update Contact Status
This process builder will update the Contact Status and Fire Process Builder fields on the
Contact record. The criteria is simply that the Bypass Validation field is true and either SAL
Task or SQL Task are also true.
Process Builder #2

12. #CD19
Clear Checkboxes
This process builder will clear the Bypass Validation, Fire Process Builder, SAL Task and SQL
Task fields. This re-establishes the validation rule from being bypassed. The criteria is that
both the Bypass Validation and Fire Process Builder fields are true. Be sure to update theses
fields in separate immediate actions.
Process Builder #3

13. #CD19

14. #CD19
Allow user actions to update records, but no manual editing of field.
Hat-Trick Consulting wants to prevent service reps from manually changing
the case status field to “working”. This field should only be updated when
the rep has logged a specific activity to the case.
Use Case # 2

15. #CD19
Unsuccessful
● Add a validation rule that prevents reps from moving the case status field to “working”
● Make the case status field read only on the page layout
● Create automation that simply updates the field based on activity creation
Result: Since the user is firing the automation from the record, they must have edit access on the page
layout. Using this method causes an error for the automation, thus preventing them from logging the activity.
Automation also catches on the validation rule if you try to leave the field as editable on the page layout.
First-thought Solutions

16. #CD19
Successful
To allow for the use case of prohibiting manually moving the Case Status
field to “working”, while allowing related activities to update this field we
will use a combination of functions that will include:
■ 1 Validation Rule
■ 1 Custom field
■ 1 Process Builder
■ 1 Flow
Actual Solution

17. #CD19
Case Object
We will add a custom checkbox field on the Case object. This will be used within the Flow an
essentially disables our validation rule. This field can be left off the user page layout, however
users need edit access. Leaving them on an admin layout is a good way to test and
troubleshoot.
Bypass_Validation__c
Custom Field

18. #CD19
Case Object
We will add a new validation rule on the Contact object that prevents users from
moving the Status field to “working” unless the new custom field Bypass Validation
equals true.
Validation Rule

19. #CD19
Launch Flow
This process builder will fire the Flow when a specific Task is related to the Case. You can
choose your own criteria, but this would run on either the Task, Event or both.
Process Builder

20. #CD19
Set Bypass, Change Status, Remove Bypass
This Flow will set the Bypass Validation field to true, then change the Status to “working”, then
set the Bypass Validation to false. A pause between separate record update elements is
required.
Flow

21. #CD19

22. #CD19
Aaron Crear
Founder & Principal
acrear@hat-trickconsutling.com
@aaroncrear
Other Tips
• Turn on field history tracking for
the fields used in the automation
• Develop audit reports
• Test, re-test and test again
• Create notifications or dashboard
components based on the contact
status change

23. Thank you!