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