Home of Field Dump
Export Salesforce Data Model to Excel
** NOW AVAILABLE for FREE on AppExchange**
https://appexchange.salesforce.com/listingDetail?listingId=a0N3A00000EJg2hUAD
https://appexchange.salesforce.com/listingDetail?listingId=a0N3A00000EJg2hUAD
We had a previous rant at how lacking changesets are and that ant based deployments bring advantages.
One of the big drawbacks of changesets are that, although they can be cloned on the same org, there is no out the box way to reuse a changeset on a different org.
Having said that, changesets also have some useful features.
As Salesforce developers why can’t we use both methods interchangeably? Well, we can.
This post addresses how changesets and package.xml files can be generated from each other.
With a bit of work, you can do the following:
Changeset to Package.xml
This routine allows a package.xml file to be generated from an existing changeset.
Use ant retrieve command. Give credentials to the org with the changeset, and include the name of change set in the packageNames paramater.
<target name="retrieveChangeset"> <mkdir="changesetfolder"> <sf:retrieve username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" retrieveTarget="changesetfolder" packageNames="changesetname" /> </target>
Package.xml to Changeset
We can again use ant to do the reverse. This could be useful for easier, automated, repeatable and quicker changeset creation.
Although ant can’t create a new changeset it can change the components in an existing changeset. So create an empty changeset first.
Set up your source data package.xml to have the <fullName> tag match the changeset name.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <fullName>MyChangeset</fullName> <types> <members>testController</members> .....
Also change the name of the metadata folder to use the new changeset name.
Then use the ant deploy command to move your components into the waiting changeset.
<target name="populateChangeset"> <sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" maxpoll ="${sf.maxPoll}" deployroot="MyChangeset" autoUpdatePackage="true" singlePackage="true" /> </target>
Best of both worlds? At least it gives us some options.
Salesforce provides a CLI tool that adds a useful bow to the developers and administrators armoury.
Note that this tool is different to the CLI tool used by dataloader.
Download from here: https://developer.salesforce.com/tools/forcecl
It is available in different flavours for Windows, Mac and Linux.
In Windows case, the download is an exe, so just copy it somewhere and then navigate to it with a command prompt. Run ‘force’ to get the help list of commands:
Some Examples:
Login:
> force login
This launches browser where you can type creds and allow cli access. You can also use -u and -p flags to provide username and password (with security token)
Run a Query:
> force query “select name from account”
View a Record:
> force record get account 0010Y00000ULl7XQAT
Update a Record:
> force record update account 0010Y00000ULl7XQAT name:”University of Boulder”
List fields on Object:
>force field list account
Export metadata to file system:
>force export
And more… (Will try and add to this list as we work through it… let us know your favourites)
Braindump: The ‘internet of things’ IOT concept has been around for a while now but in 2017 how much has it really influenced our everyday lives? We take internet access on our phones and tablets for granted, but we haven’t exactly embraced connected fridges that can order you some replacement cheese when the present block has gone AWOL and is well out of date. How many people strive to be the owner of an all-seeing, ordering chilling device? Perhaps if it could also email me some cheese based recipes before said cheese has departed…?
Thinking it through though, I have a number of IOT connected devices running in my home and they are all actually quite useful:
But where does Salesforce fit in this landscape?
Some thoughts on improving (the already excellent) Trailhead experience. Comments welcome. Let’s see if we can get make a Bronze Tent Peg a thing!
Need more ranks – The ranges are almost defined on an exponential scoring scale, topping out with Ranger awarded at 100 badges, 50k points – with 260 badges now available we need some higher ranks.
Add two new higher ranks:
Not all badges are equal – and that’s fine – more points are awarded for the more complex ones. It’s actually possible to get 100 badges with relatively low scores.
Add an award for achieving certain scores, irrespective of the awarded badge count:
Add an award for holding all Superbadges (currently 6)
Introduce more Superbadges:
Assess Progress:
How am I doing compared with other trailheaders? There are some external, opt-in tools that provide leader boards, but provide something built in that provides simple metrics on where you are in general terms… top 25% etc
Add function to allow users to build and maintain a league. Other trailheaders can be invited to join. Show summary page with ranking, progress, badges, points and super badges.
Minor gripe – Badges or Modules? – introduce consistent naming
*footnote: Ice Master… I had a relative who had that job title. He served on whaling boats in the 1840s, directing his boat though icepack ranging from unstable and shifting to hardpacked and impenetrable. They were often frozen in over a winter season (or longer) before being able to return to port. He ended up on the doomed franklin expedition to find the north west passage with indications that the crews resorted to cannibalism before vanishing. I describe this job as about as far away from a desk job you can get and worthy of top rank!
Right, we need to let off some steam. After some time working with deploying using Ant, we needed to switch back to working with changesets and it has re-surfaced some long-held distaste for them. Between page refreshes, it has reminded me about several pain points and just how lacking changesets are.
Now we all know that DX is coming and there are other slicker way of deploying, so there are alternatives, but it’s difficult to understand why Salesforce has allowed changesets to work like this – clunky, neglected and unloved for years. With some simple additions it could be a whole nicer experience.
The Problems:
Some Suggested Improvements:
A developer has added some new code in the dev org. Testing it can’t be an after thought but sometimes with all the things going on it can get overlooked or delayed and you can be in for nasty surprise when the next full test run is activated. The new change has caused an existing test to fail with an un-intended knock on and that now needs urgently fixed.
A great thing to do to try an improve the development process is to schedule all the test classes to run frequently. This allows early detection and then resolution of tests failures that may have been caused by recent dev work.
There are different scheduling options. It could be scheduled to run once a day on every development org or it could be set up to run based on something happening – when code is checked in, for example. An email, containing details of failures can be sent to the dev team. (A morning inbox present)
The actual process can be completed in several ways but we have had success using Jenkins with Ant and the Salesforce metadata toolkit.
If you have multiple triggers on an object you need to be careful. The order in which triggers run is not known so strange things can happen if triggers conflict with each other. Multiple triggers can work fine if properly designed to not conflict with each other but it can introduce a maintenance and complexity overhead. Multiple triggers can also consume more resources (soqls etc) and you can start hitting limits.
A much better approach is to have one trigger per object.
To allow this trigger to handle potentially a large number of different scenarios, introduce a trigger handler framework. This means that the trigger itself is simple – it calls a trigger handler class that will hold the logic. (So the actual trigger and the logic are separated.)
There are a number of trigger framework examples out there.
https://developer.salesforce.com/page/Trigger_Frameworks_and_Apex_Trigger_Best_Practices
http://developer.force.com/cookbook/recipe/trigger-pattern-for-tidy-streamlined-bulkified-triggers
http://chrisaldridge.com/triggers/lightweight-apex-trigger-framework/
A Trigger framework can help in trigger management by:
A trigger framework can introduce some other useful features.
Deactivation – To deactivate a trigger can require a deployment, which can be painful and time consuming.
The trigger framework can introduce an alternative way of deactivating trigger function. The trigger itself is always left on with run control added to the helper class.
Custom setting values can be used to determine if a particular part of the trigger operation should run or not. Custom settings can be set manually or updated on mass with a dataloader update. The whole trigger doesn’t need to be activated, you can introduce fine control and allow deactivation of only certain features.
Recursion Control – Triggers completing an update that then causes the trigger to rerun can be a problem.
https://help.salesforce.com/articleView?id=000133752&type=1
They loop for while and will hit a depth limit. Build in recursion control into your framework to avoid this ever happening.
Recently Salesforce has announced that Trailhead badges will form an integral part of Salesforce certifications. It’s an interesting development, here are some thoughts…
With the continued expansion of Salesforce it is important that the supply of quality Salesforce engineers to administrate, configure and develop is also grown to meet these increased demands.
With this expansion in the number of Salesforce professionals it is also important that high standards and quality are maintained.
Having Salesforce certified engineers is a great way of identifying that staff have the knowledge needed, however it not the only consideration.
Many of the certification tests are purely multi-choice questions; it is quite possible to swat up the notes and pass an exam without ever having logged into a Salesforce org. It’s not a very practical exam. Certs should be done after a period of hands on experience; it’s validating your existing skills. Who would you rather employ? Someone with certification but no experience or someone with loads of experience but no certs?
Trailhead has gameified Salesforce training, it’s a paradigm shift in making training materials more accessible, interactive and practical.
The student is able to choose their path to progress through structured and guided training while keeping energised earning new badges, unlocking superbadges and gaining trail rank.
Traditional drier tutorial content is combined and enhanced with practical examination on a real Salesforce instance with exercises tested and scored.
Treat SOQL calls like gold dust. With complex triggers it is easy to approach and breach the SOQL count limit so it important to ensure code is optimised to reduce SOQL calls and generally be as efficient as possible. Also, it is not a good idea to hardcode record ids in your code.
A great win, to reduce SOQL calls, is to get Record Types ids by using a describe method. (This method counts against another limit but saves a more valuable SOQL call.)
YourObjectName.SObjectType.getDescribe().getRecordTyeInfosByName().get('YourRecTypeName').getRecordTypeId();
eg:
id accountMasterRecID = Account.SObjectType.getDescribe().getRecordTyeInfosByName().get('Master').getRecordTypeId();
Salesforce documentation here: http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_methods_system_sobject_describe.htm