If you have kids you’ll know how disgusting a sandbox can get. Just keep that in mind as you read this post and think about how it applies to some of the things you’ve done in a Salesforce sandbox over the years.
One thing I’m really growing tired of is dealing with half-baked tests, proof of concept examples, and random fields with no descriptions in the sandbox that I’m using to deploy changes to Production. Part of the reason for this is that prior to the Spring ’16 release Enterprise Edition orgs only got a single sandbox. So if an admin is trying something new, they only have one sandbox to work in. As of the Spring ’16 release you now get 25 with the same edition. This post is going to talk you through how to leverage one or more of those 25 to stop screwing up the sandbox you need to make real deployments from, and separate your playground from your deployments.
*Hint – not a real email address*
This is a quick post to show you guys why I decided to cut yet another completely free Developer Edition of Salesforce for the sole purpose of attending and functioning at Dreamforce this year.
Even though I consider it a strength, my wife would say that I’m slightly compulsive when it comes to planning itineraries, especially around travel. The more I looked at the Dreamforce15 app the less comfortable I got with relying solely on it for my travels. Hopefully everyone gets to see a few reasons why getting more than one developer org can be helpful, even for small and short use cases like this
My last blog post was on July 8th, which is over a month ago. It turns out that you get a lot busier when your baby starts to crawl and you hadn’t quite baby-proofed the stairs yet. Who knew? Someone should really warn you about these things.
It seems like all my time is now eaten up with:
- Picking my son up off the floor, pulling the dog bowl out of his grasp, and moving him back to the living room
- Eating and sleeping
Pretty much in that order
So instead of my planned Login Flows v2 that I thought I would have easily completed by now, I thought I’d write a quick post on a few other things like becoming an MVP, Dreamforce, GTD, and what I have planned for some upcoming blog posts.
It’s not often I get excited thinking about the possibilities for something, but as of Summer ’15 I don’t see a reason why every Salesforce org shouldn’t have at least one Login Flow queued up and ready to be used at the switch of a custom setting
Login Flow is one of those underrated pieces of Salesforce that people just haven’t started using yet. I think that entering the world of Flow can be scary for a lot of people, and at first glance it also appears relatively inflexible. You can set a message, but you have to set the same message for everyone in a profile, you assign it by profile, and to change the message you have to create a new version of the flow. Just saying the words “New Version” is enough to scare off clients with a structured deployment and ALM process
This question came up on the Success Community today which triggered my memory on the release notes, which got me thinking how we can really make this work and be flexible for both messaging, and also the timing of when the message is used.