Lock Out Record From User Edit, But Allow Process Builder Edits

Question

I'm looking for the most efficient way to accomplish the following: Stop Users via Validation from editing a record when a specific field is BLANK, but allow Process to edit the record at any time.

Another way of looking at it: What "user" does the Process Builder operate under?

Situation:

Accounts are created. A LOOKUP field exists that is BLANK at first (looks to object "Customer"). In 30-60 seconds, the record is supposed to allow a Process Builder routine to edit the record (but not users).

Is there a way to know Process Builder is the one trying to edit the record, so it can be allowed to bypass Validation?

A temporary field won't work(..?) because it would be set and cause the bypass to happen for anyone.

$User.UserType also appears to be useless here.

In pseudo-code:

and( 
  isblank( NeededField__c ),
  $User.SystemOrHuman = "Human"
)

...... this would Validate (block) a human from touching the Record until the NeededField__c is populated.

---

UPDATE: Related to this - Does Process Builder Run as User or System?

---

A CLEARER USE CASE:

Accounts are created.

This causes a (custom object) Customer to be created, which links itself to the Account via Apex. No control over how this managed package does this.

We have a Process Builder that, when a new Account appears, sets a few values automatically on the Account, then Time Lapse, runs a Flow that links the Account to the Customer. We control this. This happens one minute later using "5 hours before Created Date" as the reference.

Due to that "one minute later" logic in the Process Builder, if you TOUCH the Account prior to the "one minute", it breaks the update and it never happens, ever. I want to allow the Managed Package to let it's Apex code run (typing this has made me realize it may technically be allowing Apex, not Process Builder, to bypass the Validation).

Answer 1

Process Builder runs "as the user", but with "system permissions." This means it can perform operations the user normally couldn't. As such, I think the easiest way to do this would be to write the validation rule as:

NOT(ISNEW()) && ISBLANK(NeededField__c)

Have NeededField be read-only for the user so they can't manually manipulate the record into being editable ahead of time.

As a related concept, perhaps you could use a short trigger to just lock the record:

trigger onObjectX on ObjectX (after insert, after update) {
    ObjectX[] locks = new Object[0], unlocks = new ObjectX[0];
    for(ObjectX record: Trigger.new) {
        if(record.NeededField__c == null) {
            locks.add(record);
        } else {
            unlocks.add(record);
        }
    }
    Approval.lock(locks, false);
    Approval.unlock(unlocks, false);
}

I'm pretty sure there's other alternatives as well of various complexity, but I hope one of these will help you.

Answer 2

As a workaround you could

1. write a trigger / code to allow the fields the PB is updating to be edited but no other fields. Downside would be the user could edit those as well...But it may be a viable workaround.

2. Override the edit button. Have it take to a VF page that checks to see if it can be edited. If not show a message that the user cannot edit the record and a button to take back to the detail view. If they are allowed to edit then take to standard edit page with the nooverride parameter set to 1

Item 2 would cover all bases but would take a small amount of code to work.