Preface: this post is part of the Write Your First Advanced Trigger series.
When faced against impossible coding projects, I remember something my mentor once told me.
Always remember this, it will serve you well during your career!
Anything is possible with code. Remember that even the most complicated programs can be broken down into smaller and smaller pieces, until eventually, every component is simply a true or false decision.
Today I’ll introduce to you this chapter’s trigger and how to apply our simplification strategy to it.
Write a trigger that shares read/write access to an Account with each member of its zip code Territory.
A few notes about this project:
Let’s assume these are the objects and fields available to you:
Now to simplify this trigger, we simply start from the top and break down each possible decision into smaller and smaller pieces until what’s left are basic, easy-to-do code statements.
Here I’m using a free Flowchart tool called Gliffy:
Even if the entire flow chart looks scary, if you focus on each individual node, it’s a piece of cake!
Really, go through each step and see for yourself!
Note that this trigger makes extensive use of the AccountShare object. This is an Apex-editable junction object between Accounts and Users that lets you edit their corresponding access levels.
Also, don’t forget we need to Bulkify these:
Next post: Turning a concept into code – begin writing an advanced trigger!
In looking at the custom objects you created in your org for Territory and Territory Member I noticed you have API names of “regalray1__Territory_Member__c” and “regalray1__Territory__c”. When attempting to create these objects in my own org I am unable to generate the same API names. Any ideas??
LOL the permissions in the org are way too open and looks like someone other than me set the namespace. Ignore the regalray1__ part and just use Territory_Member__c etc etc!
I just tried to log in to your org to check out the objects needed for this trigger (Territory, particularly) but I am unable to log in (username or password may be incorrect, contact…). I used your updated login details.
Perhaps I have not gotten there yet but your trigger code does show before trigger for the update; however you replied after trigger for the update!
Oops I misspoke! We use “before” on the update because the ID already exists when we refer to it. We use “after” on the insert because the ID doesn’t exist when we refer to it!
Looking really fantastic trigger. :-)
Let me know if I am correct in below understanding of this trigger:
1) Trigger runs when we are inserting or updating Account record: means we need to write trigger on ‘after insert’ and ‘after update’ events.
2) After insert or update of Account record, we will fetch Account record’s ZIP code. Using that ZIP code we will be searching the Territory.
3) If we are getting any Territory for respective Account’s ZIP code, then we will be querying all Territory Members(which we can say User) for respective Territory.
4) Once we will get related Territory Members, we will share Read/Write access to Account(which we have created and updated in point-1) for all Territory Members(which we are getting in Point-3) using AccountShare object.
Please let me know if I am understanding it correctly.
You’re 100% spot on Amit!
I’ll go into greater detail on how to translate this into code in the next post!
For the update trigger would it be a Before as opposed to an After?
After because of this!
Also more detail here:
Thought post but didn’t see it so if it come It comes in twice I apologize…
Perhaps I have not gotten there yet but your trigger code does shoe before trigger for the update; however you stated after trigger.
The site gets a lot of spam so comments need to be manually approved hehehe