I’ve had a tinker with Flows in my spare time but like most things you only really get to know them when you actually have to use them. Unfortunately for me up until now tinkering is all I have been able to do and I haven’t felt like I had anything to add to the already fairly comprehensive opus of work on Flows. That is until today when I was actually presented with an opportunity to make use of Flows in real life! My use case was simple, take a list of records and update the value of one field on them all – the value of which the user must be able to select.
My recent work has had me having to create a series of custom publisher actions. “Old news” I hear you say. And it is publisher action seem to have been around forever and plenty has been writtne on the whys and wherefores of them, so I don’t want to rehash that information here. Instead I want to share a very small quirk of the Salesforce1 mobile app in relation to custom publisher actions and custom icons.
This weekend sees the Salesforce London Summer of Hacks event and along with three others I will be judging the entries on Sunday afternoon. I am really excited to be a part of this event even if I’m not packing my laptop, Pro Plus and sleeping bag!
Visualforce extensions provide a quick way to add some otherwise non standard functionality to your pages whilst at the same time making use that you have access to all of the standard goodness. However we need to just exert a little bit of caution when doing this as permissions come into play and can cause some behaviour which you might not expect.
So Salesforce1 Dev Week is over and what a week it was! I was lucky enough to be at the Developer User Group in Bristol, UK and was excited to see so many people turn out for the evening. I think the best thing for me was the fact that half the people in the room had never see the Salesforce1 mobile app before. I take these things for granted, I’m lucky enough to be in a job which means I get to see this technology and play with it, whereas the DUG reminded me that most people don’t!
So, a week ago I helped double the number of local developers that knew of this fantastic new world but that is just the starting point. The next step is to at least double the number of developers that knew about Salesforce1 in the entire UK. A lofty goal I know, but I have a secret weapon at my disposal: the Salesforce1 World Tour on May 22nd.
VisualForce pages get served from the visual.force.com domain right? Generally speaking, yes. In fact since back in 2009 when VisualForce pages were moved into their own domain to make applications more secure this has been the standard process.
This is an interesting piece of history, for sure, but it’s not quite the whole truth. It turns out that there is a permission that Salesforce have access to which will revert to the old behaviour and VisualForce pages will be served from the salesforce.com domain. I’m not privy to the whys and wherefores of having such a permission but it exists and occasionally as an ISV we trip across people that have this option enabled on their Orgs. I say trip over because it causes some inconsistent behaviour to occur which always causes our application to barf.
Person Accounts are loved the world over and their foibles are well documented. However I struggled to find any particular reference to this little gem and as a form of therapy and to serve as a remind for future generations I find myself duty bound to make a note of it.
For some reason the Name field for a Person Account object is not provided in the Trigger.new and Trigger.old collections. I appreciate that this field is an almalgmation of the FirstName and LastName of the related contact but it seems inconsistent to drop the field completely from the object in this one circumstance.
A New year is upon us and last year’s Dreamforce is all but a distant memory to most of us. I learnt a lot and had a great time but I don’t want to dwell on that too much. Instead I want to answer a question that I was asked in my Designing APIs session that I couldn’t provide a good enough answer to at the time.
The question was around how to deal with versioning an Apex API in a managed package. My advice at the time was to try to not have to version things. And whilst I stand by this it wasn’t particularly helpful; there are obviously going to be times when you have to make changes, breaking changes that mean you need to completely remove methods from your code. So how does this work in Apex?
I was having a conversation over lunch a few days ago when I was asked “what originally drove you to Salesforce?”. I surprised myself a little with the answer: It was how quickly I could make changes to the system – how quickly I could take a business process and free it from the shackles of spreadsheets and post-its and turn it into a fantastic, computerised, cloud based system. This impressed people around me too, in particular business owners, I got sucked deeper into the rabbit hole and the rest is, as they say, history.
It was the “Clicks Not Code” that actually won me over. Obviously I went on to get a deeper understanding of the platform and how to develop on it, but in the first place it was the declarative nature of things that drew me in. And I know that I am not alone in this fact, in fact this is one of the real powers of Salesforce and something that developers forget all too easily.
Every day is a school day, or so the saying goes. And today has once again lived up to that adage.
I have been creating a webhook to allow me to load invoice data into a mutli-currency enabled org. I have dealt many times with multi-currency orgs and have never had any problems with them. However today that was not the case. I knew that to set the currency of a record to something other than the org default you need to set the CurrencyISOCode to the ISO Currency Code for the currency that you wish to use. Until this afternoon this was the limit of my knowledge on the subject, however that quickly changed when I found myself receiving the DMLException: INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST
The values in a normal picklist are case insensitive; that is, if the values available in the picklist are: A, B and C and I insert a the when I query the data I will find that the record has been inserted as A – brilliant, it’s a consistent behaviour and better than that a lenient behaviour which helps to drive data consistency.