Run Trigger As A Specific User (or Profile)?

Question

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...

Answer 1

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).

Answer 2

One option is to remove the Validation Rule entirely and enforce the same rule(s) in the trigger. This will give you more flexibility to bypass the rule as required.

If you enforce the rules in a before insert/update trigger you can use addError method to show any errors on the page or against a particular field.

You will probably want the trigger to run in what is known as the "system context". When running in this mode it won't be limited by the current users sharing rules etc...

You can alter your Apex Controllers to run in the system context by using the without sharing keywords if they are currently using with sharing.

See Using the with sharing or without sharing Keywords

---

UPDATE: This is only applicable to test methods

Seems like you were almost there with your "Run As" terminology.

There is a System.runAs(user) method that allows you to run tests as another user.

See Using the runAs Method.

Answer 3

Try excluding those three profiles in the validation rule by adding $Profile.Name to the Error Condition Formula. Something like:

AND(
    NOT(OR(
        $Profile.Name = 'profile1',
        $Profile.Name = 'profile2',
        $Profile.Name = 'profile3'
    )),
    ... your regular validation rule here ...
)

On a related note, I have a similar requirement where Closed Won Opps are very locked down. I ended up writing a trigger that locked 95% of the fields but white listed a handful of fields that were allowed to be changed. That idea might work for you better than the validation rule. This answer got me most of the way there.

Answer 4

If we want to run a trigger for a specific user then follow the below code:

first we have to call custom setting object there by we can get particular user id then follow the below piece of code:

trigger AvoidDuplicate on Contact_Relation__c (before insert)
{
    set<string> contd= new set<string>();
    set<string> orgcontains= new set<string>();
    if(trigger.isbefore && trigger.isinsert)
    {
        **hierachy_us__c ob=hierachy_us__c.getInstance(Userinfo.getUserId());//'getting present user id with the help of custom hierachy obj'
        if(ob.SetupOwnerId==Userinfo.getUserId())**// 'checking with the present user id'
        {
        System.debug('profile id:'+Userinfo.getProfileId());
        System.debug('user id:'+Userinfo.getUserId());
        for(Contact_Relation__c con : trigger.new)
        {
            contd.add(con.Name);
         }
        for(Contact_Relation__c dup:[select id, Name from Contact_Relation__c where name in:contd])
        {
           orgcontains.add(dup.Name) ;
        }
        for(Contact_Relation__c con : trigger.new)
        {
            if(orgcontains.contains(con.Name))
                con.adderror('this record already exists');
        }
        }
        }
} 

Answer 5

Ultimately it seems that the way to bypass this is to do what I'd normally do in Validation Rules (along the lines of what @twamley mentions) - bypass it with a value in a field (versus a Profile reference). To accomplish this more simply, I'm going to try setting a hidden field to True on the ACCOUNT, and add that bypass to the Validation Rule on the OPP. This SHOULD work..........

Answer 6

A field on Opportunity just for temporary "bypass val. rule" sounds a bit fishy. If you're willing to rewrite your validation into a trigger on Opportunity, try this:

1. Make a class (or edit existing one) that'd have a static Boolean variable called skipOpportunityCheck or similar.
2. In your Account update trigger, just before the code that goes update relatedOpportunities set this static variable to true.

3. In the Opportunities trigger where you'll have your rewritten "validation rule" go:

   Boolean canEditClosedWons = ...; // your val. rule here
   if(!(canEditClosedWons && SomeClass.skipOpportunityCheck)){
       // addError to all of them
   }
   

That way normal edit of Opportunities is blocked like it used to. Only when the "entry point" is edit of Account you'll have your bypass.

It's a tricky topic with no silver bullet. Other solutions include usage of custom settings, some flags on user object... Control Fields vs Heap "Mock" Fields for Branching Trigger Behavior would be a nice starting point if you want to dig into more generic discussion.

As others have mentioned - runAs method is good only for testing context.