“WebQuerySave” / “PostOpen” and all its siblings have been a bastion of Domino and Notes developments since time out of mind and indeed they exist in a near identical form in Salesforce but just called Triggers
Just like Notes/Domino has different events that let code ‘Do Stuff’ to records e.g. “WebQueryOpen”,”OnLoad”, “WebQuerySave” etc etc, Salesforce has the same sort of thing, in their case they are broken down into 2 parts: Timings and Events
Before: The Event has been started but the record has not been saved, this maps basically to the “Query” events in Domino.
If you want to calculate fields and stuff and change values in the record you are saving, this is the time to do that, you don’t have to tell it to save or commit the records as you normally would, it will run a save after your code is run.
After: The record has been saved, all field values have been calculated, then the After event is run.
If you want to update other objects on the basis of this record being created/saved do it here, you can’t edit the record you are saving, but lots of useful bits such as the record id and who saved it are available in the After event 1
These are exactly what they say there, Insert is like a new document creation, Update is editing an existing document, etc etc
This then gives us a total set of different event types of:
Now you can have a separate trigger for each of these events, but I have found that this bites you in the bum when they start to argue with each other and hard to keep straight when things get complex, so I just tend to have one trigger for all events and a bit of logic in it to determine what’s going to happen when
Here is my Basic template I start with on all my triggers
As you can see you can determine what event you are dealing with by testing for “.isInsert” or “.isAfter” and then run the right bit of code for what you want, again I like to keep everything in easy sight, so use functions when ever I can with nice easy to understand names.
In the above case, I want to check a field after there has been an update to see if it has been changed from empty to containing a value. you can do this with the very very useful ‘Trigger.New’ and ‘Trigger.OldMap’) as you can see below
So we are taking the list of objects3 that have caused the trigger to run ie “Trigger.New”, looping through them and comparing them to the values in the Trigger.OldMap (which contain the old values) to see if things have changed.
So that is the theory over, you can see existing triggers by entering Setup and searching for “apex triggers”
BUT you cant make them from there, you make them from the Object you want them to act on.
Lets take the Case object for an example
In setup you search for case, and click on “Case Triggers” and then on “New”
That will give you the default trigger…. lets swap that out for the all events trigger I showed above
Better, then just click save and your trigger will be live. simples..
Now there is an alternative way to make triggers, and you do sometime have to use it when you want to create a trigger for an object that does not live in the setup, such as the attachment object.
You will first need to open the Developer Console up (Select your Name in the top right and select “Developer Console”), then select File —> New —> Apex Trigger
Select “attachment” as the sObject and give it a sensible name.
And now you can do a trigger against an object that normally you don’t see.
You know that pain in the butt thing you sometimes have to do with Domino when you have to use the NoteID rather than that Document ID before a document is saved this gets round that issue. ↩
Yes eagle eyes, there is no “before undelete”. ↩
You are best to handle to handle all code in terms of batches rather than the single document you are used to in Domino, we will handle batching in a later blog, but just take my word for it at the moment ↩
Welcome to the second part of the Salesforce for Domino Dogs series. This one is a monster, but don’t worry we will be revisiting and clearing up some of the complex parts in other blog posts. What was a simple thing in Domino is quite complex in Salesforce and for a variety of very good reasons. So… scheduled agents.
Scheduled Agents: These little sods are the pain of many a Domino admin’s life. Personally I blame them for the lock-down of many a Domino server from the free-for-all that was so empowering to users, but sometimes there is no other way to get round limits or deal with certain triggered activities.
In Salesforce scheduled processes are a bit more complex than you might be used to, and this is not just a Salesforce thing, but a cloud thing—no cloud provider wants their platform just churning along in the background eating up cycles and I/O time.
So let’s break it down:
So this CAN just be any bit of Apex you want, but most of the time you will actually end up using batch apex. Batch Apex is a whole set of articles in its own right, but in this case it’s just a way of getting round the Apex limits.
… hmmm that does not help. OK let me explain:
You know how with Domino scheduled agents, they will only run for so long before the agent manager shuts it down? This is to stop you writing rubbish code that screws up the system. Apex has a load of limits just like that, and the one that hits quite often is the limit that you can only send 10 emails using Send() in a given transaction (you can send 1000 bulk email per day). To get round this limit you have to “batch”, or break up your code into chucks. In Domino this would be like saying we want to process a whole view’s-worth of documents, but in chunks of say five documents at a time.
An empty bit of batch apex looks like this:
Let’s take it apart. First we will use the “start” function to get the list of objects we want to work through, so we take the empty function:
… and add a search to say get all “contacts” in Salesforce. We only need the email address for these contacts1 so we add that as one of the fields which it gives us:
Next we want the empty “execute” function which will do whatever we want with each chunk of objects it is sent:
So in this horrible bit of code, the chunk of objects is passed in a reference called “scope” — we are then just iterating the objects and sending an email for each contact (you can see the email address stipulated in the “start” being passed in using “c.Email”):
Finally we need an empty “finish” function which runs when all the batches are done:
So let’s send a final email notification to the admins:
Put it all together and you get:
So now we need to call this code
The code we have just written won’t run in a schedule on its own, we need to wrap it up in a bit of code that can run on a schedule and decide how big the chunks will be. In this case they can’t be more than 10 as we will hit the Apex limits for sending emails. An empty schedule wrapper looks like this (I have called mine ‘Scheduled_Agent’ but you can call it anything):
Now let’s create a new instance of the batchable code we created in section 1, tell it we want it to run in batches of 5 records or objects, and tell it to execute.
Code bit all done!
Now it comes time to actually schedule the code to run at a certain time, you can set this up via the user interface by going into Setup, searching for “Apex Classes”, and selecting the result:
Select “Scheduled Apex”
As you can see, the options are limited to, at most, a daily run—you can’t specify it to be any more frequent. However, we need to run to more often than that2.
First open up your developer console, by selecting your name on the top right and picking it from the drop-down.
Now open up the “Execute Anonymous Window” from the debug menu.
You can now run Apex code manually, and as such you can schedule jobs with a load more precision using a Cron String. In this case we want to run the agent every 10 mins within the hour, so we create a new instance of our “Scheduled_Agent” scheduled class and schedule it appropriately:
Click “Execute” and you can see the jobs have been scheduled. It should be noted that you can only have 100 of these in your org and this uses up 6 of them, so some planning would be good.
And there you go, scheduled agents. Let the legacy of horror continue!
Following on from the Initial Session “Salesforce for Domino Dogs” that Paul Mooney and I did at Engage and a modified version of which that has just been presented at #DNUG I figured that a series of dev articles on how you would do a job in Salesforce that you had always taken from granted in Domino might be a good idea, because:
These articles are not in any order and are not meant to represent any form of training guide.
So lets get started, first up: Profile Documents!!
In Domino you tend to store config settings for an app in a profile document1 for all your one off settings
To get the same features in Salesforce you use a ‘custom setting’ which does exactly the same job and has one huge advantage over using a normal Salesforce custom object that could do the same job.
(It should be noted that Domino profiles are nothing like Salesforce profiles)
To create a custom setting, go into Setup and search for “Custom Settings”
Click on the “New” button, and fill in some sane details, for normal configs i.e. stuff you would use system wide, select a setting type of “List”, if you want to use them for things like default values in fields and formulas then select “Hierarchy”
Click ‘Save’ and you now have a custom setting object, you can add one or more fields to it just as you would any other object in Salesforce
Added all the fields you want?, lets put in some data. if you go back to the list of custom settings you will see that you now have a “manage” link, click this
Then click “New”
Fill in the fields just like you would on a normal form, if this is a Setting there is only going to be one of, I tend to give it the same title as the name of the object to keep things simple, in this case “General Settings”, if you are going to use it multiple times than give it a name that will make sense in the context of your code
All done. now we can use the setting in our code and see the reason why we would use them vs. a normal custom object.
As you can see from the code below, you don’t have to use a Select statement, which means getting the settings wont count against your apex limits, HORRAY!!!
You just have to create a new instance of the setting object then you can just “getInstance” with the Name of the object you created to get the document back.
Well you are supposed to, but you never do thanks to the evil caching and the fact the are are a sod to just copy around, so you end up with a config document and a view you store them in. ↩
Editing an email that is generated via an Saleforce email template BEFORE it is sent is something that I have had a few clients grumble over, the feature is baked into the Quote object which makes sense, but you try telling clients they cant have it for Order objects….
So this is a basic solution that gets round this problem and is the basic set-up for expanding it to solve all the issues, in this case I am solving the most common issue I have come access, in that you are generating a order recept or delivery note pdf using the ‘renderAs=”PDF”’ option in an email template and want to send the email with a custom message to one or more people that you decide at the time of sending.
To do that we are going to create a new visual force page that resembles a normal email and use it to fill in the details before we generate the email template
This is just a basic object with the fields we need for the email, and a lookup field to the parent Order
Note: For brevity I’m leaving out the creation of the layout for the custom object and the adding of the related list to the Order Layout
These are the temporary fields that we are using to actually send the template email, resist the urge to set the To/CC/BCC as email fields as that will stop you having multiple recipients.
Obviously these fields have to be editable to all but not part of the order layouts so they don’t show up.
This page is as simple or complex as you can want it, my one here takes email address separated by a comma but yours can be a really posh contact lookup
I have just put comments on the code, as its not complex and follows the flow chart at the top of the blog.
Now update your email templates to use the “le_Body__c” and “le_Subject__c” fields for their email contents,
So PDF’s generated by Email templates in Salesforce are not saved and you cant get hold of them, so we are not saving them in the custom email object, if you do need that, then you will need to convert your email templates to visual force pages then render as PDFs and save them in the custom objects.
It seems the need for hacks has not gone away with the move to cloud, but you do have to be more careful, as I have already found out Salesforce can break your custom code at will.
So that being true one of the things that SalesForce does not seem to have that every other framework does is a simple an powerful “hide when”, IMHO this feature should be present in every line button and object on every page and most platforms do,
It is the most requested feature for customisation that I have come across, and this is the hack that I use for read mode documents or forms (which strangely is where the request is most often made) (and yes it is a hack)
Lets break it down
We have to do a wait loop that keeps looking for the object till it finds it (then stops), because SalesForce adds button objects in after the page loads so they wont be there when it first opens
So we put this code into a Page
This insert that page into the layout Object layout we want it to effect.
that would normally give a big white space where the inserted form lives, so we make the page a 1% by 1px block
And that’s it, just save the layout, the button/”what ever” will hide when the page loads, a hack but a simple reliable hack
Now as always “hide when” is not security, remember to make sure that you don’t leave functions exposed and think this kind of thing covers you.
As @devinthecloud points out in his Blog post Salesforce Winter 16 wrecked C3 charts on the pages he and I had developed. he found the removal of <apex:form> fixed the issue on his pages, but on my page the charts were still broken, so instead of this:
You get this
I stripped the page down to a bare minimum that you can use to recreate the issue, see below,
This let me narrow it down to the Salesforce header.
when you set showHeader=”true” it breaks
if you set showHeader=”false” it starts working
As this is obviously and provably down to a change in winter 16 I can raise it with Salesforce and get a fix.
“At times, Client Side JS conflict with SFDC header JS will collide with already defined functions with the same name.”
Ah it’s nice to see that young Internet companies have the same grasp of customer service as the traditional IT companies and thus it falls back on consultants to fix, in this case with an Iframe, I’m not a fan of Iframes normally but as Salesforce use them themselves there is precedent
And so we now split our single page into 2 pages, an inner content and an outer Iframe wrapper
First we take out the existing page (it was called “chart_test”), rename it to “chart_test_inner” and set showHeader=”false”
Then we put in a Iframe wrapper with the old name and a bit of CSS to make it size properly then point it to the inner content
And now instead of a broken
We have a working