[SalesForce] Run Trigger As A Specific User (or Profile)

Is this possible? I'm not finding help, Google or otherwise, for this.

Situation:

A trigger runs and cycles through groups of Opportunities. Some of these Opportunities are Closed Won, and most users of the system are not allowed to Edit Closed Wons (especially the Sales team). But I need this trigger to be able to touch the Opps (it's fired when the User touches the Account and subsequently a group of Opps under that account gets touched). It is a VALIDATION RULE blocking them.

Ultimately, I may investigate, if no other option, setting a HIDDEN FIELD on the Opp before updating, then clearing if after, and putting bypass code in the Validation rule. This is a backup plan. I'd like to know how to "Run As" a specific profile though.

Anyone have an example of this? I have three profiles out of twelve that can touch Closed Wons…

Best Answer

No, simulating another user/profile is not possible in the scenario you describe (and an undesirable platform feature for 3rd party code security reasons). You should always build backdoors into hard-fail validation rules for this reason. I prefer doing this to enforcing the logic via triggers because then the validation rules are still maintained via clicks admin, and you can do things like add error messages to specific fields.

The pattern I follow for Sys Admin manual overrides is to exclude the privileged profile(s) from the validation rule altogether (a la twamley's note). But that doesn't get you what you need, which is a code-only override.

For situations where only code is allowed to bypass a validation rule, you've mentioned the option of a hidden field but I'd suggest a significant tweak to it. I create a (18,0) numeric field called something like "Apex Updated" that is hidden from page layouts and read-only for FLS for user profiles. In any validation rule you want a code backdoor to, you just add a check for NOT(ISCHANGED(Apex_Updated__c)). Then, in your code, to bypass those validation rules you just set Apex_Updated__c to System.currentTimeMillis(). This has the advantage of not having to reset fields, or worse yet, missing the workflow to reset them and ending up with records that are permanently exempt from validation rules.

You say it's a backup plan, but it's just one custom field, one line of Apex code (to set the field when a bypass is desired), and one line of validation rule modification (to bypass the rule when the field is changed).

Related Solutions

[SalesForce] Account Merge – Opportunity is not updated / touched

From the Apex Developer's Guide:

Merge events do not fire their own trigger events. Instead, they fire delete and update events as follows:

Deletion of losing records A single merge operation fires a single delete event for all records that are deleted in the merge. To determine which records were deleted as a result of a merge operation use the MasterRecordId field in Trigger.old. When a record is deleted after losing a merge operation, its MasterRecordId field is set to the ID of the winning record. The MasterRecordId field is only set in after delete trigger events. If your application requires special handling for deleted records that occur as a result of a merge, you need to use the after delete trigger event.

Update of the winning record A single merge operation fires a single update event for the winning record only. Any child records that are reparented as a result of the merge operation do not fire triggers. For example, if two contacts are merged, only the delete and update contact triggers fire. No triggers for records related to the contacts, such as accounts or opportunities, fire.

The following is the order of events when a merge occurs:

The before delete trigger fires.

The system deletes the necessary records due to the merge, assigns new parent records to the child records, and sets the MasterRecordId field on the deleted records. )

The after delete trigger fires.

The system does the specific updates required for the master record. Normal update triggers apply.

Thus you could have a before delete trigger on the deletion of the losing records and figure out the children that will be affected. I suspect that you might need to have some co-ordination between the before and after delete triggers, such that the before figured out the affected children of a delete, and the after confirmed that they were being deleted as part of a merge and took appropriate action.

[SalesForce] Cyclic Trigger Calls

You need to create a static variable that lives in a class somewhere and not in your apex trigger.

public static boolean firedOppRollup;

You can then set this variable from one trigger and reference it from another. The static variable can be set without instantiating your class. This is the recursion issue that I was alluding to in your other thread.

I can't really see all of your code in Trigger B but I'm assuming that it aggregates some opp data and then updates the account. You want to short-circuit the account trigger running at that point, since you've already completed your calculation in Trigger B. To put this into practice, you need to set the static variable to TRUE at the end of Trigger B, before your account DML.

Then in Trigger A, wrap all of your processing in an IF statement that checks your variable.

IF(MyClass.firedOppRollup){
    //Do nothing, the calculation is done
} else {
    //run all of your account trigger code
}

Best Answer

Related Solutions

[SalesForce] Account Merge – Opportunity is not updated / touched

[SalesForce] Cyclic Trigger Calls

Related Topic