Technical Debt

Adam Gill5th May 2020
0
Admin News: Critical Updates and Product Retirements
It’s that time of year again, with the Winter ’20 Release approaching. And with each release, there are a number of Critical Updates. In addition this release highlights a number of products are also inline to be retired over the coming year.
Let’s take a look at what these important updates are and how to prepare for the transition.
Critical Updates: Know the impact
Every release has a number of Critical Updates. These allow admins/developers to plan for a change to the platform by giving some control over when the update is released.
Background: What are critical updates?
For example, as an Admin/Developer you can choose to activate a Critical Update before its planned activation date. For example, this means if you have a sandbox environment you can choose to activate the update and test any impacts on your org.
These updates can be many and varied, some with limited impact (if any) to end users, for example by updating how HTML code is handled/displayed to a user.
Other updates, will have a very noticeable impact. Like the upcoming Lightning Experience critical update.
Winter ’20 Release: Critical Updates
Let’s take a look at the some of the highest potential impact updates coming our way. These are Updates which are ‘enforced’ by Salesforce in this release… Meaning they will be activated automatically as part of Winter ’20 release.
Lightning Experience for Users
Who will this impact? This one will automatically impact users who have the ‘Lightning Experience User’ permission.
Even Astro loves Lightning Experience…
They may have this permission because they are:
- allocated to a Standard Profile (these are the ones you can modify that ‘come with Salesforce’)
- a Custom Profile which was cloned from a Standard Profile after Winter ’16 release,
- have a Permission Set which includes the ‘Lightning Experience User’ permission.
When? Salesforce will activate this Critical Update is globally throughout October.
What you can do to prepare: Read up on the update here, and also read the Frequently Asked Questions.
The Lightning Transition Assistant, will also help give you information specific to your org on the transition. And will include things like what likely wouldn’t work in Lightning, which profiles are ready to go, etc./
Also, keep in mind that users will be able to still switch between Lightning and Classic. So that is a small grace, if you need it. But note that Users will be automatically switched back to Lightning at the start of each week.
Security Updates for Email and HTTPS Connections
What is the change? From a high level, these updates improve the general security and functionality of Email and how your browser connects with Salesforce.
Specifically, there are a number of updates to take note of:
Who will this impact? All Salesforce orgs, with users and API connections potentially impacted.
For example, the TLS 1.2 changes may impact users with old browsers. While the update re: DKIM Key is used as a way to potentially avoid spam filters in email clients.
When? As part of Winter ’20 release (throughout October). You can check the specific date for your org by going into “Critical Updates” in your Setup menu.
What you can do to prepare: Review the release notes above. Most of these changes shouldn’t require a ‘heavy lift’ from admins.
Note re: the TLS 1.2 change, a quick review how users are connecting currently should confirm they are using modern browsers. If you remember the TLS 1.0 deactivation, the steps would be very similar here. Users on current browsers should be fine – and API connections which are ‘hard coded’ to use TLS 1.1 may not connect once update is activated.
API Only Users Can Access Only Salesforce APIs
Who will this impact? Any user which has the ‘API Only User’ permission. This update ensures that these users ONLY can access Salesforce via API, and not via UI.
When? As part of Winter ’20 release.
What you can do to prepare: This one is probably the simplest. If you have a user which is impacted and they need more access – an Admin can update their permissions to not include the ‘API Only User’.
A note for Admins: Other Critical Updates
There are a number of Critical Updates, and each org is different, this means high impact updates for your environment may not be covered here. So it is recommended that you check the release notes for a full overview of all Critical Updates.
Caution: Product Retirement Ahead
Over the coming year, we see three products entering the ‘transition to retirement’.
The good news is, two of these products have direct replacements/upgrades available – so if you are still using them, you can start to plan your transition now.
Original Territory Management Is Being Retired
The first product on the list, is the Original Territory Management module (or Territory Management v1.0).
Salesforce launched the beta of Enterprise Territory Management in 2014. and has been adding new features and functionality to Enterprise Territory Management (Territory Management v2.0) over the last few years.
It has now been built into a more advanced version for managing territories, and ties exclusively into Collaborative Forecast module (and in turn Lightning Experience).
When?
As part of Summer ’20 release next year, which is likely to be around May/June 2020.
Why?
As Salesforce are pushing the Lightning Experience Transition, starting with this release (see above). They are clearly taking the opportunity to retire the Original Territory Management and Customisable Forecasting (see below) – and give an additional reason for users on the older products to upgrade and switch to Lightning Experience.
Admin actions:
Simply put, if you are still using Territory Management 1.0, now is the time to start planning your upgrade to Territory Management 2.0.
You can read more about the considerations and planning for the transition here.
Also, there is a key step when you are ready to transition where you may need to contact Salesforce Support to ensure users don’t lose access to old data as part of the migration. Read more here.
Note: If you are using Customizable Forecasts (see below), you will need to plan the update to Collaborative Forecasts at the same time as the modules are dependant on each other.
Customizable Forecasts Also Entering Retirement
Other than being spelt the American way, the time has also come for Customizable Forecasts.
Much like Enterprise Territory Management, there have been countless improvements made to Collaborative Forecast module over the last two years.
I remember a time when it couldn’t even handle custom fiscal years! And Quotas were only able to be entered by API/Dataloader until recently.
But the key here again, is that it ties exclusively into Enterprise Territory Mangaement (TM 2.0) and of course Lightning Experience…
When?
As part of Summer ’20 release next year, which is likely to be around May/June 2020.
Admin actions:
Now is the time to start planning your upgrade to Collaborative Forecasts.
If you are using Original Territory Management, you need to also plan the update to Territory Management 2.0.
You can read more about the considerations and planning for the transition here.
RIP Data.com Prospector and Clean
The final ‘old horse’ being putting out to the retirement pastures soon will be Data.com Prospector and Clean.
With GDPR forcing a rethink of how data is managed and processed. The offering for Data.com become quite limited in certain territories (specifically in the UK/EU).
Additionally, a change to licensing from D&B / etc, has meant changes to the product where inevitable.
Salesforce has worked with a number of data providers to package and distribute what is now coined ‘Lightning Data‘ via the Appexchange. This now also gives you access to additional products and services, and no doubt more will come online over time.
When?
Depends on your contract, Salesforce will essentially stop renewing this product as part of your subscription.
And the products will be retired in July 2020.
Admin actions:
You can read the FAQs here, and if you use the service your AE will likely be in touch to discuss options as part of the renewal process.
The main actions for Admins will be to prepare reports/workflows/apex/etc to stop using Data.com specific fields. You can read the Salesforce guide here.
Adam Gill14th March 2019
0
What I learnt rolling out Salesforce Lightning…
Rolling out Salesforce Lightning is something most of us have or will shortly experience. If you are an Admin, there is fewer and fewer reasons to not take the plunge and migrate over to Salesforce Lightning.
I have long been pushing our various Salesforce instances towards being able to migrate to Lightning Experience.
We had focused so much time and energy trying to reduce the technical debt to a point we could possibly make the jump. Until we made the decision to shift gears, and actually move into a shiny new org.
But moving to Lightning, has taught me a few things as an admin/dev, and it is time to share! So here are some musings/lessons/thoughts about rolling out Salesforce Lightning…
Learn Lightning, inside and out!
I got to say, there was plenty of things that stumped me about the move across to Lightning.
One that ALWAYS got me, was the difference between the Lightning Page Builder, the ‘normal’ page layout builder and what controls what on the actual overall layout in Lightning.
Simplest way to learn this, is imagine the Lightning Page as the top layer, or shell, which allows you to organise the overall feel of a specific page in Lightning.
- This is where you define how many columns you want to display, how where the columns/rows go.
- It is also where you control what displays where. And groups together things like record pages (ie the ‘normal page layout’), any widgets or components you want.
- This is where you can control the sub-tabs which display in Lightning. Like the Related sub-tab or Chatter/Activities
The thing that got me, the most when starting out?
This is NOT where you control the buttons, quick actions, etc visible on the page. For that you still need to go and edit the Record Page.
I don’t know why, but this is one thing that really irritated me the most until it finally just ‘clicked’ and made sense in my head.
The section on the Record Page Layout for ‘Salesforce Mobile and Lightning Experience Actions’ is where you control this.
But remember, you may have a Lightning page for all users. But if you have a Record Page Layout for different profiles/record types, then you will have multiple places to manage this and make sure it is correct for everyone.
Lightning is about speed and efficiency, so use it!
So use the opportunity of moving to Lightning as a way to change how your processes work. If you are migrating to Lightning, you will have to review most (if not all) processes anyway. So use this as an opportunity to work with your internal stakeholders and improve the workflow for the end-users!
Going through our transformation to Lightning, there was a ‘hit list’ of things we wanted to change.
Depending on your scope re: the project and time allowed, you won’t hit everything. But by identifying and prioritising the ‘top speed boosters’ for your end-users, helps get them engaged in the overall project. And by even improving their workflow by reducing 3 or 4 clicks, you would be surprised how quickly this all adds up to measurable improvement for your users.
Even reworking your page layouts, to display the information the end-user needs can add to the overall benefit of Lightning.
Why is this important?
Rolling out Salesforce Lightning, as a new User Interface, gives you a lot of flexibility. So the more you can do in this area, helps when it comes time to rolling out the new system and getting your users to buy-in and actually use Lightning!
It all ties back into driving engagement and adoption. Which is the reason you are doing this change in the first place, isn’t it?
It is a bigger jump for your dev team than you may realise…
Through this project, I had the benefit of working with a number of top notch dev teams, but specifically the Salesforce dev team.
But changing from Classic to Lightning, had a massive up-skilling implication for us as a company. And we ensured we gave the development team time to learn the ropes with Lightning Pages/Components/etc.
To help out, we also tried to go as ‘out of the box’ as possible. But no matter how hard you push for this, there are likely to be business rules which need customisations.
So don’t underestimate this!
Allow your dev team time before the migration to up-skill and learn about how the new Lightning framework fits together.
I would always loved to give our dev team more time for this, but keep in mind that you do have to try and balance this with likely delivery ‘windows’ within your organisation.
We had a lot of other projects happening, both before and after this porject. So we had a specific time frame we had to aim for to release in. But we made it, and I think we managed to get a decent amount of time for our devs to learn the new world.
Think about the data!
As previously mentioned, we made a decision that it would be easier for the teams involved to deliver Lightning to the business as part of a new CRM. This was instead of the option to try and update/upgrade things in a Salesforce org that was around 12-14years old!
For us, though this meant we also had to plan in a CRM Data Migration… YAY!
Now, you might not have the need to go this route. But data is still very important in the project.
What data is visible, can in some circumstances be controlled by Lightning. Do you use Customisable Forecasts? Nope not Lightning compatible, instead you will need Collaborative Forecasts. Salesforce have done a massive job in trying to plug all the gaps between classic and Lightning, but some still exist. (Like Close Date showing in US Date format, regardless of locale settings – very confusing everywhere that isn’t US/Canada!)
So, remember the data.
Remember what you need your users to do in Lightning, and make sure they still can do it.
It could be simple tweaks to page layouts (as per my first point). But you need to make sure everything that is needed, is visible to those who need it.
And where there are system or feature differences, weigh up does the Lightning alternative work for you? And if yes, what training/coaching do users need to get used to the new way of working? Then this should feed into your overall training plan, as remember, Lightning is very different for end-users!
Remember your Users (aka avoid the Bambi effect!)
Any change of this nature is going to be big! As admins and developers, we have now been conditioned re ‘all things Lightning’. And have been for a number of years – even if you haven’t used it before yourself.
Everything Salesforce related has been pushing Lightning now for a number of years…
But the biggest thing here is, don’t underestimate the change for your end-users. Remember this will mostly be brand new to them. And some will likely resist the move, at first…
One anecdote for you, which was something that I had to fight hard against myself. Don’t underestimate the impacts of some of the ‘out of the box’ features that come with Lightning. Remember as Salesforce users we have seen things like Kanban and Lightning Consoles in every Salesforce demo and feature release now for a number of years…
And this is how you want to ensure you avoid your end-users becoming like the proverbial ‘deer in the headlights’ (aka Bambi).
Oh look, new features!
When we rolled out Salesforce Lightning, our sales and finances team LOVED Kanban View on their relevant list views. But it was something that was easy for the delivery team to skip over or avoid, because for us we had seen it all before, and it wasn’t part of what we were actually developing…
But we didn’t deliver that as a feature… Or did we?!
Sometimes the project team got a little disheartened, myself included. Why? Because the meetings you go to with end users, they would always say how ‘we love these things’, but those were the Salesforce Lightning ‘out of the box’ features, like Kanban.
But to make those features work and work properly for your teams, there is a lot of effort that is needed to ensure they work as expected. You have to adjust all the things that go on ‘inside’ Salesforce, in the places end-users don’t really see! Like your workflows and validation rules. These things simply have to be in-sync with what you are trying to deliver with Lightning.
So we might not have created Kanban, but we did everything behind the scenes that makes it work fluidly/’drag and drop’ in a system. We updated the workflows, approval rules and validation rules behind the scenes to allow users to be able to ‘simply drag and drop’ records into the new status.
In the old classic workflow, we would just throw up a validation error (not best practise, but so many orgs do this), if something was missing. But now moving to Lightning, this gave us a huge opportunity to rethink how/when certain information got entered in Salesforce.
Rolling out Salesforce Lightning? Engage the top brass, and the foot soldiers
A project on this scale, will need so many different people to be involved.
Success is paramount on engaging the top brass (ie senior leaders/stakeholders) and getting them involved in the process. And likewise, you have to also get the foot soldiers (or your super users) comfortable enough to be able to help take some of the questions.
We treated this as much of a culture change, as it was a system change. And that seemed to work really well for the project.
There are a lot of ways to do this, and you can search until the cows come home about Change Management practices. But put simply you and your team will need allies and generals. People on your side to help push your message across the teams / organisation and drive adoption.
And the biggest lesson here, is to remember that everyone reacts to change differently. Doesn’t matter what it is.
But by treating this like a cultural change, and preparing to support people as they went through the ‘change curve‘, you can help ‘short circuit’ the pain of change. You won’t get rid of it completely, but you can come up with a plan that helps people transition through to the ‘new way’ as quickly as possible.
Rolling out Salesforce Lightning, can impact people differently. The ‘change curve’ highlights a number of outcomes…
And finally…
There is a lot to go through. The key to success really is to plan. I have touched on a number of facets to what we learned as part of our Lightning migration. Everyone has a different starting point, both re: Salesforce instance but also experience with driving changes within an organisation.
Planning your project will put you in good stead, and by scheduling in the change on your roadmap, you can use it as a golden opportunity to revisit almost everything to do with how Salesforce works at your organisation.
As part of this revisit, decide what are the must-haves and things that need to change, versus the nice-to-haves. And also use this as a chance to try to identify any risks to the project.
But don’t just focus on ‘must-haves’. Sometimes the nice-to-haves are the things that also help you get people excited about a new system…
Comments below!
Have you recently moved across to Lightning? What are your tips or lessons for moving to Lightning?
Or if you are planning on moving to Lightning, what are the things you are most looking forward to (or nervous about)?
Adam Gill14th September 2018
0
A Tale of Salesforce API Limits
Everyone loves data, I am sure of it… The key difference though, is most people in their right mind, simply wouldn’t admit it. Data is useful, particularly in this day and age, in what is now commonly referred to as the Information Age.
Now, you might be thinking I am crazy – and that is probably true – but data is the life-blood of modern-day organisations. So what happens when can’t query, transform or extract your data because you hit Salesforce API Limits?
Intro to APIs….
Ok, ok – I hear you. What the hell is an API limit? For that matter, what the f*** is an API? And why should you care?
Starting at the beginning (feel free to skip this section if you already know this!)…
An API, or Application Programming Interface, is at its most basic a way programs or systems talk to each other. I am way over-simplifying things here. But an API ultimately allows one piece of software to communicate with another piece of software in an agreed way.
APIs allow computers to talk to each other
Software, like Salesforce, is built to be a relatively open platform. And they do this by using a number of APIs to allow other bits of software to communicate and link to it. These links allow developers to do things like query, extract, create or update records within Salesforce with relative ease.
Salesforce supports SOAP API, REST API, BULK API, Streaming API, Metadata API, etc…. So there is a number of ways to access what you need.
Tools you may use as an Admin everyday, use a variety of these APIs. For example, DataLoader uses the SOAP/REST/BULK APIs depending on its setup. Likewise Workbench supports APIs too, as it can connect and manipulate data, query the fields, test API connections within Salesforce.
Even tools like Salesforce for Outlook use APIs to query records and insert attachments. And as an admin this is why you should care. These tools, along with many others, use APIs to connect to Salesforce.
But with great power, comes great responsibility…
So with all these connections into and out of Salesforce globally, surely that can slow down the platform?
That is what brings us to the Salesforce API limits.
Salesforce is a multi-tenanted platform, meaning no-one company has an exclusive server/computer/machine setup for them, everyone shares the infrastructure which drives the platform. So being cloud-based, Salesforce needs to ensure the performance of the platform works for everyone.
To do that, Salesforce impose limits. Governor Limits, Storage Limits, Per User Limits…. All based on the version you have bought from them.
These limits are designed primarily to cap usage of the platform, ensuring stability of the platform and still give a fair amount of flexibility. All the while, also providing a potential upsell opportunity for extra Salesforce services (eg Data Storage limit).
Salesforce API Limits
Among these limits though are API Limits. And even though you normally shouldn’t notice there are limits in place, when you do hit the limits – especially when you hit them unexpectedly – it can be a little jarring…
```
System.Web.Services.Protocols.SoapException: REQUEST_LIMIT_EXCEEDED: TotalRequests Limit exceeded.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
```
This is the error which stops all work via APIs… If you rely on APIs to connect to your systems – you really don’t want to see this message!
In this example, a connection using the SOAP API to connect into Salesforce has reported the Request Limit has been exceeded…
Diagnosing API usage…
As an Admin, to diagnose the issue the first port of call is to analyse and find out how you hit the limit.
Every org has quick look view at the API limits. So go ahead – check for yourself. Go to Setup | Quick Find | System Overview to see what you have within your org (if you have access to the Setup/Config of your org that is…).
Not quite there yet… But closing in on the daily API limit!
Firstly, all this really confirms is what has happened. Like a car not starting, you have confirmed there is a problem – but you haven’t diagnosed the issue.
When is 24hrs, not 24hrs?
And secondly, when is the 24hrs? Is it a rolling 24hr period, is it the start of each day local time or even the start of the day in San Francisco?
Well, the good news is this limit is a rolling 24hr period. Meaning it shows you the last 24hrs, from the time you are checking the limit. This is important to know, if you have a lot of batch processes which might be scheduled at specific times of the day.
Is that all the information you need?
Does that really help you though? Overall it doesn’t really give you much insight as to what has really happened within your org.
So, what about Company Information? There is an API Request Limit there too…. (Go to Setup | Quick Find | Company Information)
Company Information in Setup
Nope… still not much help! In this example (yes, two different orgs), we can see the API Limits is 98.9% at the limit for the day. So you will likely start to see problems with API connections…
API Usage Last 7 Days
On the Help page, Salesforce referenced an ‘API Usage Last 7 Days’ report, but didn’t mention where I could find the actual report!
The help article advises that you need: ‘View Setup and Configuration’ permission on your to see this report. I definitely have this permission within the org…. But I still couldn’t find the report:
Then I was reminded about the fact Salesforce comes with some generic but useful standard reports. And guess what is included in the folder!? Yep, an API Usage Report 🙂
But you need to go via the Administrative Reports folder in Classic to view it… Go to Reports | Folders | Administrative Reports:
Salesforce API Usage in Last 7 Days Report
If that doesn’t work for you, you can also use this URL hack (thanks to Joshua) to jump to the report within your org:
```
https://na1.salesforce.com/00O?rt=104&retURL=%2F00O&c=UN&c=FULL_NAME&c=EM&c=CID&c=TS&c=CC&duel0=FULL_NAME%2CUN%2CEM&scope=organization&details=yes

Replace the na1 with your instance.  Below is the same url without the na1.salesforce.com
	
	/00O?rt=104&retURL=%2F00O&c=UN&c=FULL_NAME&c=EM&c=CID&c=TS&c=CC&duel0=FULL_NAME%2CUN%2CEM&scope=organization&details=yes
```
Diagnosis, complete…
Well… Almost….
The report gives you a great breakdown to see what/who is using up your Salesforce API Limits over the last 7 days. But it doesn’t fix the overall issue. The fix itself can be as complex as the software/tool that is causing the API Limit to be used up!
But at least you can now diagnose the issue and decide if you can fix the issue, alternatively if it is something you aren’t likely to be able to fix/reduce you can sometimes buy additional API Limits from Salesforce by speaking with your AE…
Adam Gill17th June 2018
0
Is it time to move to Salesforce Lightning?
Salesforce Winter ’18 has now been rolled out across all Salesforce instances. As you have noticed, Salesforce Classic didn’t get many feature updates, and almost the entire release is Lightning Experience focused. You might have noticed the trend over the last few releases – seemingly everything Salesforce has done has been labelled ‘Lightning’ or only available for the Lightning Experience… So is it time to move to Salesforce Lightning?
How did we get to this point? It feels like only a little while ago, we were all talking about key missing features. We will take a look at the history of Salesforce and how Lightning came to exist. What features are now available to you in Lightning Experience?
Stepping back in time…
Back in 1999, things were different. Let’s take a step back in time…
To connect to the internet, if you were lucky enough to be able to get it, your computer had a modem which made really funny noises and it could take a minute or two for it to simply connect with your ISP.
Not an iPhone in sight… Even the 3310 wasn’t available in 1999!
Mobile devices looked quite different. There were no iPhones or Android’s. Even the Nokia 3310 hadn’t been released… It was released in 2000!
The world used Lycos, Hotbot or Yahoo to search… Google had only started in 1998 and not many people used it (or even knew what Google was!)
Do you Yahoo…?
But 1999 also revealed Salesforce to the world. And over that time there has been a number of UI improvements but the core of Salesforce has always been the navigating via tabs.
Salesforce: a brief history…
The world has changed considerably since 1999. And so much of it, for the better!
Internet in many offices now is super-fast broadband, some would even say “Lightning fast” (#sorrynotsorry, I couldn’t help myself).
Internet speeds on mobile are also significantly faster and now we take for granted the ability to use internet on our mobile devices (let alone being able to stream Netflix on a mobile device).
As a result companies switched to a ‘mobile first’ approach to development, Salesforce included. This resulted in spending a number of features that became exclusive to mobile devices. And as the Salesforce1 app on mobile devices continued to evolve the desktop version started to really look dated.
Some people even resorted to using the “One App” on desktops to gain access to these new features. This was mainly to test app features, but none-the-less there were stark differences between desktop and mobile.
And over the last few years we can even add into the mix devices like smart watches, which allow us to be even more connected to our work.
Introducing Salesforce Lightning
This is why Salesforce needed to evolve again.. Enter Salesforce Lightning Experience (otherwise referred to as LEX for short).
Lightning Experience across all devices…
It was designed as a way to unify the interface across all devices. While also introducing a new wave of web technologies to the CRM for admins and developers to be able to leverage.
Lightning Experience (LEX) promised a whole new interface and way to interact with Salesforce. When launched it was features like kanban boards for sales to manage their pipelines, news highlights & account news, sales path and being able to put graphs on list views which caught the eye of most admins and developers.
That isn’t even mentioning the new design framework and components which let you extend the functionality on pretty much any page. Lightning Experience suddenly expanded the world of point and click admins!
Lightning – started with a flash…
As with any transition though, not everything was working as expected. Lightning Experience was quite cumbersome and sluggish to use. And so many features of what became Salesforce ‘Classic’ weren’t even available in the new user interface, as an example Forecasts wasn’t available at all.
Since being introduced as part of the Winter ’16 release, Salesforce was aiming for feature parity with Salesforce Classic within 2 years. Over that time there have also been a huge number of improvements made. Which begs the question, is now the time to move to Salesforce Lightning?
Salesforce has not only improved how Lightning loads, but improved how Lightning looks and also introduced a range of brand spanking new features to Salesforce platform and only available in Lightning (looking at you Salesforce Einstein).
Salesforce Lightning versus Classic
Over the last two years the list of missing features in Lightning has been thankfully shrinking. As you can see from the Salesforce feature comparison, we are fast approaching the milestone of feature parity in Lightning Experience.
Clearly Salesforce isn’t just looking at feature parity, with Lightning “exclusives” such as Dialer, Assistant, new dashboards (not with just three columns) and even new report graph types are being released only on Lightning.
Salesforce Kanban and list view graphs (Source: Salesforce)
You can also forget about using Salesforce Einstein sales features if you haven’t migrated…
Looking at the list, there are still some specific exceptions. But not being able to migrate to Lightning Experience due to a missing feature is now mostly a thing of the past for organisations.
Final verdict: Move to Salesforce Lightning
Lightning Experience has come a very long way since it was first released, and is now ready for most organisations to make the switch.
Standout features in Lightning Experience do grab the eye of users and admins alike. This is quite beneficial as it can help drive user engagement and adoption. And ultimately this can help make the change to Salesforce Lightning an easier process.
But now is the time to start planning the upgrade to Lightning Experience.
Remember though, you do have to plan carefully for it (which we will cover in the next post).
Most organisations should now be able to start using Lightning without having to keep switching back to Classic. Even if there is a feature still missing, the Lightning Experience roadmap shows the future product releases. Check it out to see if your missing feature is about to be released.
What do you think? Share your thoughts below in the comments section.
Adam Gill5th December 2017
0
Cleaning a Salesforce Org
Data is such a big focus for anyone working with a CRM, Salesforce is no exception. Previously we looked at migrating data into Salesforce. But what happens when you need to remove data? Cleaning a Salesforce org can present a few challenges.
Say you need to clean your Salesforce org and delete/archive, because… you might have gone over your Salesforce data allowance?
This is what happened to us recently. One of the orgs my team manages went over its allocated Data Space, and we started getting emails / calls from Salesforce to remind us that we have used up our allowance.
We had a choice, buy more storage (at Salesforce’s very inflated data prices). I mean c’mon it is 2017, 1TB with Dropbox/Google/Onedrive/etc is only around $100/year…
As you can probably guess, this wasn’t our “go to” option, so we had to find out what we had in Salesforce vs what we needed, and then make a decision…
(c) Dilbert
Legacy org & technical debt
The org in question was what I deem a “legacy org”, and has had presented a few challenges over the years. It has been an active Salesforce org since 2003. And without constant love and attention has built up so much technical debt because it was never actively managed/improved/developed…
Even relatively simple things like enabling and rolling out Chatter were never done – even years after Chatter launched.
Clean Your Salesforce Org: Our org was a balloon waiting to burst
As the company has grown, obviously so has the data stored within the org.
Add into the mix that new apps installed in the org which have driven a sudden increase in the volumes of records being created (eg telephony integration and training people to log calls). And hey-presto data storage & how we are using it is suddenly a priority.
Where is the data?
For an org which has grown from around 50-100 people in 2003, and a very simple business processes. The question was how could we be using up out data storage suddenly?
Why now? How do we get to the bottom of what is happening?
Admittedly it wasn’t something we had kept an eye on. So the first port of call was the setup menu.
As you might know Salesforce offer a section in the Setup menu called ‘Storage Usage’, which is quite basic but gives you a snapshot of where your data and file storage is used. To use it, go to Setup -> in Quick Find, and search for ‘Storage Usage’.
Boom, there it was.
The org with over 23,000,000 records…
The org had ballooned to over 23,000,000 records. Shocking as our number of accounts are a fraction of that overall volume.
What was even more shocking for us was that it was two objects consuming almost 70% of the total storage!
Yes those numbers are real… We needed to clean our Salesforce org!
The two objects in question: Tasks & Email Messages…
<sarcasm> Oh joy! </sarcasm>
Not all objects are equal
Why was I so *not* excited that it was Tasks & Email Messages using up our storage?
Salesforce Tasks & Archiving
Activities in Salesforce have a unique feature which means they get archived by Salesforce after a set number of days. This is typically around 365 days of being closed (but there are a few caveats to that), and can also be extended if you request it from Salesforce.
This is an issue, as once archived you can no longer use the standard Salesforce reporting to analyse.
And due to the sheer volume of records (over 12,500,000), it was even crashing Dataloader/Workbench/Developer Console when trying to export the data.
When I did manage to get the export, by trying to filter by created year, the file was still too big to view in Excel. Also we were limited to just Excel, which meant we hit a brick wall.
Email to Case & Email Messages
This org heavily relies on Email-to-Case. And when received, the email is stored in the EmailMessage object.
Additionally all auto-response emails are also saved against the case, in addition to any replies from the customer.
Great for keeping track of all communication. But once again creates some difficulties when trying to report and analyse.
Also as an email gets saved against a case, it also creates a task. So we end up with a sort of duplication, with a task and an email message created and linked to the same case.
Getting the data out of Salesforce
In the end we contacted Salesforce Support, as we couldn’t use normal methods to export and clean the data.
The only suggestion that Salesforce could provide was to schedule a data export of the objects we wanted to export and analyse. Simple enough…
Anyone who has used this feature will know the output of this is zip files, which contain CSV files inside. Great it was going to be small enough to work with!
Nope… Each CSV was still over 1,000,000 rows.
Excel still was too unusable to analyse the data. At this point I really was wishing for something like Access/MySQL to load the files into.
Enter CSVSplitter, a really simple tool that allowed us to split the CSV files down into smaller more manageable chunks.
Once they were broken into the smaller files, then we were able to start analysing the tasks.
Analysing the data
Inspector Gadget time!
The road to cleaning a Salesforce org is paved with lots of data to analyse!
You need to understand what you have, before you can understand what you need.
So we started analysing the data. And we dissected the data in many different ways to understand what was driving the volume we were seeing.
We looked at tasks created by month and year. Were there specific users who created more than others? Were there common subject lines – which might point to auto-generated tasks.
Our Salesforce, had never ever been cleaned. And we have used tasks in the past to drive system automation within the business. So where relevant, these records could go!
Archiving the data
So we had analysed the data, now to archive it somewhere in case we actually needed to reverse the process. (FYI – while researching this post, I found this useful guide to creating a Archiving Policy for your company).
Though storing the records outside of Salesforce and then trying to restore in the case of a profile would be painful if we had to. But at least we had a fall back plan, and if needed the business could still use in reports.
In addition a lot of care was taken in being conservative with what we are removing and working with various stakeholders to ensure the different departments were on board with our plan.
Now we could start the actual cleanup!
Cleaning a Salesforce Org: 2,600,000 records deleted (so far)…
I have to admit, this part ended up actually feeling strangely cathartic.
Being able to delete over 2.6 million records from an org was also a first for me 🙂
We essentially identified the records to be deleted, creating a CSV file of the IDs of the records we wanted to delete, and then use Dataloader to remove the record.
Once we started with the tasks, we were able to then also move on to other records and start an overall clean out of Salesforce. Opportunities, Accounts, Cases… All are now in scope and we have created a data clean-up roadmap and are making great headway.
We have a long way to go still, but at least we can start to let go of the legacy data past.
And most importantly, make Salesforce a focused CRM for the sales and customer service teams, so it is easier for them to use.
Still a long way to go… But we shall prevail!

Got your own ‘lesson learned’? Share your tips…
I have worked in org’s where hitting the data storage limit was expected and almost required. As we deployed tools like FinancialForce which create a lot of records (and they need to). So we simply bought more data. But it really depends on your scenario, as every orgs needs are a little different.
Have you been in a similar situation? How did you decide what to archive? Did you use any specific tools to help you?
As part of this issue, we were able to make a business case for getting tools like DemandTools (paid app).
And I am currently investigating Passage Tech’s ‘Storage Helper‘ and ‘Rollup Helper‘ (both have a limited free version) to see if they can help profile accounts to then identify what records can still be removed and archived from Salesforce. But I will save the details for another post later 😉
Adam Gill20th June 2017
0
Reminder: Salesforce & TLS 1.0 being disabled
As an #AwesomeAdmin – are you aware of which of your users is going to be affect by TLS 1.0 being disabled in Salesforce?
Hopefully the answer is NONE! But the July 22nd 2017 is fast approaching, have you gone through the checklist to ensure you are ready?
First things first though.
What is TLS 1.0? And why should I care?
Salesforce has an explanation on the Help article relating to TLS 1.0 being disabled:
TLS stands for “Transport Layer Security.” It is a protocol that provides privacy and data integrity between two communicating applications. It’s the most widely deployed security protocol used today, and is used for web browsers and other applications that require data to be securely exchanged over a network. TLS ensures that a connection to a remote endpoint is the intended endpoint through encryption and endpoint identity verification. The versions of TLS, to date, are TLS 1.0, 1.1 and 1.2.
Salesforce web and API connections, along with email delivery, use TLS as a key component of their security. HTTPS (web) and STARTTLS SMTP (email) also use TLS as a key component of their security.
In reality, what does this mean for you? TLS is a protocol which provides security for you and your users when they log in to Salesforce. This can be either via the website, like when a user goes to login.salesforce.com, or it is also used when a user logins to Salesforce via an app (like Salesforce for Outlook, Web to Lead, Open CTI, etc).
After TLS 1.0 has been disabled, any login attempt using that protocol will simply fail, unless TLS 1.1 (as a minimum) is support.
When is TLS 1.0 being disabled?
Salesforce has previously moved the effective date for the TLS 1.0 disablement to give Admins more time to catch up, but I wouldn’t count on Salesforce moving this again.
As it stands Salesforce are planning to disable TLS 1.0 on the 22nd July 2017.
How do I check?
In Summer ’16, Salesforce updated the Login History reports in Salesforce to allow Admins to check what type of TLS connection is used. The downloaded file will also show you 6 months history, and will show the TLS Protocol being used.
To access this, go to Setup -> use the Quick Find to search for ‘Login History’ -> Select ‘TLS 1.0 Logins Only’ -> Click the ‘Download Now’ button. Please be mindful, this report can take a while to download if there is a lot of TLS 1.0 logins!
Hopefully, this is an empty or only a few records in the file for you. One of the orgs I have recently managed had a lot! And it was all down to Salesforce for Outlook needing to be updated for all users.
From there, you should be able to narrow down what needs to be updated to then get it fixed.
The good news, is most up-to-date browsers will already support TLS 1.1 or higher. And the Salesforce apps like Salesforce for Outlook have supported this change for almost a year… If you are on the latest version of the software, it shouldn’t be a problem.
Need more help?
Because this has a potential big impact on customers, Salesforce has provided a lot of support documentation and guides. They have even published a checklist to download and run through if you need more help.
- Knowledge Article: TLS 1.0 being disabled
- Success Community: TLS 1.0 readiness checklist
- Post your questions to the Salesforce Infrastructure Success Community group and follow the discussions on “BeTLSReady” and “TLS 1.0 Disablement.”
Adam Gill9th May 2017
0
Summer ’17 Deep Dive: Salesforce Optimizer
What is Optimizer?
Simply put Salesforce Optimizer is a reporting tool which gives you valuable insight into areas which may need addressing within a Salesforce instance.
The report is very easy to read and I can’t tell you how much I love Salesforce Optimizer. Want to define some areas of technical debt to target? Optimizer is here to help! What more could an Awesome Admin want?! 🙂 Working across two instances (a legacy org and a new org), this report gives me insight into areas to focus on and this feeds directly into our roadmap.
But it isn’t just for old orgs. You would be surprised how many newer instances also have some areas to address. With Salesforce Optimizer report, you can easily analyse some of the common pain points in any org.
And now it is even better in the latest Summer ’17 release. The team behind Optimizer now have added in some additional areas to analyse!
Identifying Technical Debt
Salesforce Optimizer covers quite a few key areas every Salesforce admin should keep an eye on. It is a great place to start if you are looking to do a spring clean of your org or reduce an org’s technical debt.
Currently it evaluates a number of setup and configuration areas and generates a really insightful report. The report provides easy to understand breakdown on what is the issue, why it should be addressed and what you should do to fix it.
In the Spring ’17 release, it went live covering the following areas in Salesforce:
- Field Usage (object limits & usage)
- Apex Triggers (limits)
- Custom Layouts (page layouts, record types)
- Validation Rules (active & inactive)
- Sharing Rules
- Workflow Rules
- User Permissions (specifically who has administrator access)
- Profiles/Permissions Sets
Salesforce Optimizer & Improvements in Summer ’17 Release
As part of Summer ’17, Optimizer also gets a number of improvements. There are three key additions as part of the Summer ’17 release and they are:
Are you ready for the Summer ’17 release?
Profiles and Permissions Sets
In Summer ’17, you can now find any profiles/permission sets that aren’t allocated to any of your users. The fact these are now included in the report is fantastic, and definitely helps remove some of the clutter.
In my opinion there is still more that Optimizer can do in this area. For example comparing profiles, so difficult in Salesforce… But for an easy way to compare permissions and permission sets, I recommend using Perm-Comparator. It is a free tool and works wonders!
Locate hard-coded URL references
Hard-coded URLs can cause links to break when you make certain changes to your org (like activate your custom domain). They also present a problem if your org ever goes through a Salesforce org-split, as the server location may change as part of this process.
Users’ login activity
Also in this release, Salesforce Optimizer now reports your users’ login activity and then flags users that haven’t logged in recently or never activated their accounts.
Other general improvements
With all software these days, a new release gives the development team the chance to update the service with some general user tweaks & bug fixes to the report.

Feedback with the Product Team
The Optimizer Product team are listening. If you want to provide feedback you can go to the Release Readiness & Feature Adoption group and use the topic ‘OptimizerReportFeedback‘.
Adam Gill6th March 2017
0
Why creating a roadmap is important
How can planning a roadmap be used to support your Salesforce org? Especially when it is used by more than just one team in your the business. How can you ensure you deliver what is truly needed? How do you prioritise your efforts?
What is a roadmap?
First thing first, let’s have a quick look at what a roadmap is.
Change is the only constant, how will your business adapt?
A roadmap is a strategic business planning tool often used to outline the future vision of a system(s) or product. It will show what changes and development is needed to get there and will visualise the items you plan to deliver over a specific timespan.
So how does that relate to Salesforce? In a world that is full of change and competing priorities, business is no different. There will be new bugs and issues to fix. New business priorities which may change the strategic direction, resulting in changes to the system. As a result, any roadmap will need to continously evolve as the business priorities change.
A system roadmaps is most often used in Agile delivery environment, and will help stakeholders visualise where/when any planned improvements are likely to happen.

But why is it important?
Imagine your working on a jigsaw puzzle. You know somehow it all fits together, but you are not sure what you should focus on first. All the pieces just seem a bit random at the start. Then slowly but surely you start to set a strategy in place. A plan of attack for solving the puzzle.
Maybe you start by putting all the edge pieces in place first, followed by any pieces that relate to distinct image that is part of the puzzle. Then over time as you have more and more of the pieces in place, you start to see the image come together. Now imagine you are working on the jigsaw puzzle with other people. How will can you make sure you are all aligned and working towards the same goal?
To me this is essentially what a roadmap is and why it is important. Breaking the puzzle into smaller focus areas allows you to create a strong foundation for tracking your progress as you go along. And by setting a strategy in place, you should be able to deliver the finished result quicker than if you just tried to solve it in a random / unplanned fashion.
As an example of a roadmap, Monzo (a start-up bank here in the UK) openly publishes a Trello product roadmap for their apps, detailing the features planned running against a timeline (short term, medium term, etc). If you want to check it out, you can view it here.

How do you create a roadmap?
Where do you start? Planning your roadmap is an overall, continous process. But by taking the time to define and maintain it, you continually evolve what the future vision looks like and become more proactive about where Salesforce will grow/develop – which in turn should minimise those ‘why didn’t I know about it’ moments.
There are a number of steps you can go through, and by all means this isn’t a definitive list. Also keep in mind that project methodolodies (eg Agile) may also play a part in the ‘how’ and ‘what’ you need to define.
Identify stakeholders & research
If you are starting from scratch, identify your key end-users & stakeholders (Sales, Finance, Marketing, IT, etc)? By knowing who to go to, you can then research what is important to your business. Ask what are their key priorities for the year ahead. What improvements would they love to see made to Salesforce? If you don’t have a relationship with your stakeholders, this will helps to open the door. And will also come in handy later on.
Innovation & ideas
You might also have your own improvements or changes you want to make to Salesforce. After the last post, you might have identified potential technical debt within your Salesforce which needs to be addressed.
Also what about new features and innovations you want roll out. Things like a move to Lightning UI? All of this will need to be added into the mix too, as remember we need to balance out all of the priorities as we won’t be able to do it all at the same time. 🙂
By combining the earlier research with your own ideas, you now have a list of different and competing business priorities. But how do you sort through the list?
Setting the business priorities
Firstly some priorities which get raised will simply be so critical to the business that the priority and timeline will almost be set for you. For everything else, here is where you can get creative.
One idea is to get your key stakeholders together in a room. In this session encourage people to be open and transparent, while keeping everyone focussed on what is best for the business and not individual departments/teams. Going around the table, everyone who raised a priority gives an elevator pitch to the group covering where they see the value of the request. As each pitch is given, a card or post-it goes up on the wall.
After the pitches are finished, give out three sticky dots to everyone (or you can simply use pens). Next tell them to place two dots next to the idea they would prioritise first and one dot on their second priority. The aim is to get some overall coordination on what to focus on first, where the priority is driven by the highest amount of dots – where you sort the cards by descending order. Close out the meeting by going around the table again and confirm if people agree with the outcome.
By involving your stakeholders in setting your roadmap, you allow them to buy in to the future vision of the platform.
Unfortunately there can be circumstances where stakeholders can’t come to a conclusion. This is when you would become a little more direct. The group should at least try and seperate out the list into what is needed versus what’s a nice to have. If this still doesn’t work, you may need to get an appropriate Sponser (possibly a senior leader within the business) involved.
Visualise the roadmap
Roadmaps come in all shapes, sizes and formats. It is important to realise that they are generally high-level in nature. Covering the themes and objectives you plan on delivering. Save the detail of what needs delivery for a project plan and the team involved in delivery.
Personally, I have I tend to only set a roadmap for the next 6-12 months. And then bundle everything else together under a header of ‘future items’, but you can be as creative as you want. As mentioned earlier, these plans are subject to change. Aim is to make it easy enough to adjust moving forward.
When it comes to estimating the time and effort, there will be an element of making an educated guess on some of the work involved. Ask around the Salesforce community and see what others estimate. If there is a vendor/partner involved, they can also give you an idea of the effort involved.
Another very simple example of a roadmap would be to group items by a theme down one column, and have your timescale running along the top. Then your individual deliverables/projects become the cells in between. Here is another example of what you could do simply in a spreadsheet:
Example of a roadmap
There are plenty of other alternatives out there though, just do a Google image search for other examples! As mentioned above, you can use a bit of creative license here. Just make sure it is easy to understand what you are trying to convey.
Communication
Now we are near the finishing line of this whole process.
After putting all of this together, play back the outcomes with key stakeholders to get a final sign-off. Doing this allows any further alterations to be made. It also ensures that everyone has bought in to the process and vision, meaning you can then focus on delivery.
And remember to revist the roadmap roughly every six months.

Wrap up
I will reiterate that this is just one way to come up with a roadmap. The process can vary depending on the size of your business, what the priorities are and even lines of accountability within your company.
For an additional resource there is a great Trailhead module (Innovation Solutions), which covers the topics of roadmaps and implementation planning.
I would love to hear from you and your experiences when setting a roadmap. Please feel free to add in the comments below any steps you take in creating a roadmap.
Adam Gill8th February 2018
0
How to tame the Salesforce ‘technical debt’ beast
Previously I raised the issue of technical debt, which is an issue that can easily impact any Salesforce org.
Trying to find out just where to start can feel like trying tame a wild beast. We’ve all been there… Questions like, is it really a problem? Where do I start? How to I gather the information I need?
Help is at hand, when you are scoping size of the problem, there are some amazing free tools you can use to really zone in on your org’s problem areas.
New Salesforce features
The last two Salesforce releases have also brought new features to support you in checking your org. Let’s take a quick look at them both. Please keep in mind, to use both of these new features you will need to check your permissions and license edition of your org.
Salesforce Optimizer
Spring ’17 has brought with it the new Salesforce Optimizer. It is a great new feature giving you an easy to understand PDF report. Which focuses on some of the key areas within your org where Technical Debt might be hiding. The report will highlight key areas including:
Sample of a Salesforce Optimizer report
- Fields
- Apex triggers
- Page layouts
- Report types
- Validation rules
- Workflow rules
- Sharing rules
- Administrator permissions
To access Optimizer right now, jump to Setup -> Optimizer.

Salesforce Health Check
In the previous release, Winter ’17 also introduced Salesforce Health Check. This one is very much aimed at reviewing your org’s security policies, and as a result is a little more ‘techy’.
The report will give you an overall baseline score, recommended areas of focus and suggested actions covering:
Salesforce Health Check
- Certificate and Key Management
- Login Access Policies
- Network Access
- Password Policies
- Remote Site Settings
- Session Settings
It is very helpful and useful in performing an audit on these key security areas.
To find this within your org, head on over to Setup -> Security Controls -> Health Check.

Other Resources
Salesforce Toolkit
Another great resource I have used is the Salesforce Toolkit. It is a must-have suite of free Heroku apps which allow you to analyse, diagnose and configure a variety of Salesforce items. It does offer up to seven different tools (at the time of writing), and I have used a number of them personally across various orgs of Salesforce.
Org Doctor
I found this tool before the Spring ’17 release came out, and introduced Salesforce Optimizer. However this tool still provides some additional information that is helpful when diagnosing any technical debt within your org. Particularly helpful in highlight potential problem areas in your Apex (like API versions and number of test classes) and additional details about your role hierarchy.
The report it generates once again if very helpful and even contains a brief summary as to why each metric is important to the overall health of your org.
Schema Compare
Another fantastic app from the toolkit. This one presents an extremely helpful report comparing multiple instances of Salesforce.
Yes, you read that right! Compare two orgs side by side in a single report, which breaks it down object by object. The two orgs can be a mix of Production <-> Sandbox, Production <-> Production or Sandbox <-> Sandbox.
An example use case could be to compare a development sandbox with production to see what are the differences object by object.
Perm Comparator
The final app I want to share with you today is the Perm Comparator. Another simple Heroku app which allows you to easily compare Profiles, Permission Sets & Users within an org. Genius!
Say for example you wanted to see how two Profiles within your production org actually differ. This app makes it so simple to view the profiles side-by-side, showing how the user/object permission vary between them.

Now go forth and slay the beast!
There is never a better time than now to start slaying the technical debt beast, and with these tools you should make short work of it. Of course, there will still be other areas that may need analysis. But this should give you an idea of where you are starting from.
My next post will look at setting a roadmap, which will help you prioritise and deliver improvements for any identified areas from above.
As always, feel free to share in the comments below. Do you know of any other free tools that can help in analysing and defining where an org’s pain points are?
Adam Gill24th February 2017
7
Technical debt in a legacy org
Does technical debt keep you up at night?
The bogey-man that is technical debt can sneak up on you when you are least expecting. It adds complexity and delays releases, and is something you always have to remain vigilant of. But you can master it, and minimise its impact…
What is ‘Technical Debt’?
Let’s just jump straight on in and define the topic of today. I sourced this from Wikipedia:
Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward.
Based on that definition, can you start to think of parts in your Salesforce which may cause issues when you try to release a new feature? Technical debt and a legacy org can easily go hand in hand. But it doesn’t have to. It does rely on proper governance to minimise the challenges presented and stop them from becoming unwieldy.
A legacy org
As my first post alluded to, I am currently working with a legacy Salesforce org.
When I say legacy, I mean 10+ years on Salesforce!! Now as you might imagine, this presents some unique challenges for the business especially as we try to drive growth across the business.
What are some of the challenges? Things like the custom fiscal year feature were enabled, for no reason, within the org. In turn this blocked us from upgrading from Customisable Forecasts to the newer Collaborative Forecast module… (FYI this did change in the Spring ’16 release)
We also have countless workflows on certain objects. These perform core functions for a number of our teams, but means it is a challenge to unpick these one by one. Instead there was a plan B, by requesting Salesforce Support to increase our workflow limit.
Help is at hand
After doing a bit of searching I have just stumbled across this video. I strongly recommend watching this session, as it details how AON reduced technical debt within their Salesforce instance by setting up strong governance practices. For me this is quite topical, and as a bonus it looks like it was from Dreamforce ’16, so quite a recent discussion!
Now these issues can pop up in any org, it isn’t a problem exclusively for legacy orgs.
The key really is to address the issues head on and address any deficit in your roadmap. Then you need to ensure that there is governance in place to help maintain and prevent the org from returning to its former state. And finally, this needs to be communicated, with all stakeholders onboard.
P.S. I will take this opportunity to apologise as well. This theme of technical debt is one that I dwell a bit over the coming weeks 🙂 My next post will look at some of the tools I have used to define and quantify where the debt is in your org…

Critical Updates: Know the impact

Background: What are critical updates?

Winter ’20 Release: Critical Updates

Lightning Experience for Users

Security Updates for Email and HTTPS Connections

API Only Users Can Access Only Salesforce APIs

A note for Admins: Other Critical Updates

Caution: Product Retirement Ahead

Original Territory Management Is Being Retired

Customizable Forecasts Also Entering Retirement

RIP Data.com Prospector and Clean

Learn Lightning, inside and out!

The thing that got me, the most when starting out?

Lightning is about speed and efficiency, so use it!

It is a bigger jump for your dev team than you may realise…

Think about the data!

Remember your Users (aka avoid the Bambi effect!)

But we didn’t deliver that as a feature… Or did we?!

Rolling out Salesforce Lightning? Engage the top brass, and the foot soldiers

And finally…

Comments below!

Intro to APIs….

But with great power, comes great responsibility…

Salesforce API Limits

Diagnosing API usage…

When is 24hrs, not 24hrs?

Is that all the information you need?

API Usage Last 7 Days

Diagnosis, complete…

Stepping back in time…

Salesforce: a brief history…

Introducing Salesforce Lightning

Lightning – started with a flash…

Salesforce Lightning versus Classic

Final verdict: Move to Salesforce Lightning

Legacy org & technical debt

Where is the data?

The org with over 23,000,000 records…

Not all objects are equal

Salesforce Tasks & Archiving

Email to Case & Email Messages

Getting the data out of Salesforce

Analysing the data

Archiving the data

Cleaning a Salesforce Org: 2,600,000 records deleted (so far)…

Got your own ‘lesson learned’? Share your tips…

What is TLS 1.0? And why should I care?

When is TLS 1.0 being disabled?

How do I check?

Need more help?

What is Optimizer?

Identifying Technical Debt

Salesforce Optimizer & Improvements in Summer ’17 Release

Other general improvements

Feedback with the Product Team

What is a roadmap?

But why is it important?

How do you create a roadmap?

Identify stakeholders & research

Innovation & ideas

Setting the business priorities

Visualise the roadmap

Communication

Wrap up

New Salesforce features

Salesforce Optimizer

Salesforce Health Check

Other Resources

Salesforce Toolkit

Org Doctor

Schema Compare

Perm Comparator

Now go forth and slay the beast!

Does technical debt keep you up at night?

What is ‘Technical Debt’?

A legacy org

Help is at hand