Have you ever received one of these mysterious messages from Salesforce mentioning “expiring Self-Signed certificates“? Salesforce sends 4 notifications per expiring certificate. These emails are usually source of panic and confusion.
For a certificate to expire without you knowing what it is used for, typically means that it’s been automatically created “behind your back” by one of the processes mentioned below:
An AppExchange application generated a self-signed certificate as part of its installation process
When you receive one of these emails, you basically have two options:
You do indeed need a self-signed certificate and have to maintain it
You don’t actually need any certificate and just want to stop receiving these scary emails
Do I really need a certificate?
The certificate is required when using Salesforce as an IdP (Identity Provider). This is the case when you’re login to external systems using your Salesforce username and password. It tends to be the other way around (SSO) but, let’s check:
Check the bottom section “Service Providers”. If it’s empty, then this org is not acting as an IdP and you can simply ignore this message and the following ones. Salesforce will continue to function as usual and you won’t receive another batch of emails next year
How do I renew a certificate?
If you’ve found one or more service providers you may want to check if they are actually used. If you keep at least one service provider, then, you need to take action on the email message from Salesforce:
In Setup, navigate to “Certificate and Key Management”
The life of an IT manager is made of many decisions leading to long-term commitments:
Choice of technology (.Net vs. Java).
Choice of vendor (IBM vs. BMC).
Choice of architecture (on-premise vs. cloud).
And then, there’s the famous “Build vs. Buy” which is as much about computing as it is about business operations and risk management. In this post, I’m reviewing this IT classic in a Salesforce world…
Because it’s now an old age question, the advantages of both buy and build are well known. So, I’m just listing them as reminders below.
Fast implementation speed All capabilities being pre-built, the implementation time is reduced to installation and configuration.
Business process improvements The software business logic is built around best practices.
Benefits of scale savings The cost of each line of code is shared between customers. The vendor can invest more in security and innovation.
Resilience The software has been tested by many users and customers before you.
Support Support is available from both the vendor and the community.
Zero technical debt The vendor’s business model guarantees a high level of documentation and skills.
Feature granularity The solution can be tailor-made to exactly fit the current business process.
Short terms costs savings This is the easiest way to cut corners.
Business advantage Automates a company business process with a software which is not available off-the-shelf.
Keep IT busy The skills required to build are available and unused.
Although you can build on the Salesforce platform, it is essentially a member of the “Buy family”.
The Salesforce equivalent of buying is making the most of the components already available on the platform by favouring button-click configuration over code (say 80% code). Think of replacing most of the out-of-the-box business logic like approval processes with code to work around current feature limits. Although technically possible, I don’t recommend it for the main reason that it’s not part of the platform’s DNA, Salesforce started as a highly configurable on-demand CRM with the original strategy to reduce the need for IT involvement (click-no-code). Coding capabilities were rapidly added and, yes, using them all in the same project is possible and exciting for the nerd in you.
Unfortunately, this will also most certainly lead to technical debt. Still, this is what big SIs, coming from the world of J2EE bespoke apps, tend to favour and rarely think twice before building complex, unmaintainable systems.
Also, custom code doesn’t benefit as much from Salesforce constant innovation as much as standard features do.
Think again, you either go with Salesforce, or you go alone…
Don’t Do It
Not doing it is the new kid on the block of enterprise application design, sadly not a popular one though. In the old days, upgrading software was a multi-month long project and IT was often reluctant to upgrade a production environment for the sake of adding new features. As a result, there was quite a lot of pressure on implementation teams to squeeze in as many features as possible on v1 because nobody knew when will they get a v2. As a result, building often was an attractive option. Now, here is the game changer:
These three facts remove the pressure on feature richness and, instead, offer new capabilities you’ve never dreamt of (mobile, AI, IoT, …). In my post “The million dollars picklist“, I’m telling the story of a customization which has gone too far the custom build way!
When blocked by a feature’s current limitation, don’t start coding, start thinking… Align your application roadmap to Salesforce’s own one. For the bits you don’t know about, the best way to remain compliant with future releases is to stay as standard as possible (buy, don’t build too much). You’re not obliged to say “yes” to all requests from your stakeholders, but you’re obliged to provide good advice! Many businesses are doing great running on “non-perfect” lean apps, whereas others are struggling to grow trapped into technical debt issues of what’s become a bloated org.
Writing code is fun! Thing is, you’re not here to have fun but to leave behind a resilient enterprise class application.
When several admins or consultants work side by side on the same Salesforce org, it’s often difficult to keep track of configuration changes, especially if teams are remote and no CoE is in place.
There are many reasons why you should get yourself a forensic tool to investigate configuration changes:
Suddenly broken features are hard to fix. Checking what’s been recently changed in your org is the first port of call. For instance, enterprise orgs share some configuration areas between Apps and departments. Opportunities may be only used by the Sales team but then Products may be shared between the Sales department and Customer Service. If the Customer Service administrator modifies a Formula field on the Product object this might impact the Sales App and the Sales administrator will need to know that.
When things go pear shape, it’s always good to be able to learn from what went wrong: some changes may have been applied directly into production, a code freeze may not have been respected, a junior admin may have done a mistake, etc… Although some will see this as a way to blame others, I prefer to see it as a way to improve a process.
It can also be useful to track down who built a specific feature that needs to be improved or refactored. Who created this custom object, who last touched this workflow rule, etc… Granted, its author may have left your company but that’s another story and at least you get some contextual information.
Listing Configuration Changes
To list configuration changes, navigate to Setup, then type Audit in the Quick Find box. This will narrow down the menu options to View Setup Audit Trail. This page shows the last 20 changes done to your org. It can be useful when reacting to a recent change. But if you really need to investigate what happened to your org then you will want to pull more data.
Today, there are three ways to list configuration changes:
1. 🖥️ View on screen the last 20 changes from the View Setup Audit Trail.
1. 📄 Download a CSV file containing the last 6 months of changes.
1. 🤖 Run a SOQL query via the SOAP API on the sObject SetupAuditTrail and get every tracked change.
The CSV file uses the same format as displayed on screen. The SOAP API implementation introduces a couple of differences:
SetupAuditTrail.Display pulls the data from the Action column, and SetupAuditTrail.Action is, in fact, a short version of the Action column – yeah, I know…
Source Namespace Prefix is not exposed to the API.
Here is a list of the fields queryable and their equivalent column in the CSV file:
Action: short version of the Action column.
CreatedById: Id of the User column.
CreatedDate: Date column.
DelegateUser: Delegate User column.
Display: Action column.
Id: record ID not available in the CSV file.
Section: Section column.
The closer you can get to the CSV file is by running the following SOQL query:
/* WHERE CreatedBy.Profile.Name = 'System Administrator' */
ORDER BY CreatedDate DESC NULLS FIRST
Again, Source Namespace Prefix is not queryable.
Customise the WHERE clause to your exact need or get rid of it for a full dump.
Drop the LIMIT for a full dump.
Depending on what you’re after, these three methods should be useful to help you find who’s changed what in your org, but if you need to dig deep you’ll have no other help than your fluency in SOQL. Several months ago, I needed a tool to do an in-depth investigation and created a Google Sheet for this purpose.
Spotting Unexpected Changes
To get cracking with your investigation, you need to go through the following steps (I’ll provide a better explanation at the end of this post):
Upload the data in the Log tab of your Google Sheet.
Start your investigation from the Dashboard, then the Data Cruncher and finish with the Log.
The big picture
Navigate to the Dashboard tab and you’ll find two charts.
The first chart is a timeline of the changes made to your org year to date. This may help you to communicate with key stakeholders about the various phases of a project and how is the charge distributed, what are the trends, etc…
Just below is a pie chart showing what changes are about (Admin, Config, Dev). This can be used in a weekly report to discuss the amount of development, but cannot be related to the actual effort or cost: resetting a password counts for as much as writing a class! The split is based on the data from the Categories Setup tab.
The Data Cruncher tab is a pivot table pulling its data from the Log tab. I’m proposing a default setting with Categories and users’ Names as rows and Months as columns. This gives you a “who was doing what each month” but the idea is to let you massage the log data by trial and error. Play around with the rows, columns, filters and values, this will give you different perspectives each time.
Playing around with the tool will let you discover interesting information you were not even looking for!
Once you’ve narrowed down your scenarios in the Data Cruncher, chances are that you’ll want to drill down to the individual change level. For this, the best is to return to the source of the data, the Log tab. Using the various column filters, you’ll be able to return some pretty accurate information.
To take ownership of this spreadsheet and customize it to your taste, you need to understand how it works. The output is done on the Dashboard and Data Cruncher tabs. The input is the Log tab. The Categories Setup tab enriches the Log tab with categories (Dev, Config, Admin).
To start analysing your setup audit trail:
Empty the cells in columns A to E of the Log tab (do not empty the grey columns).
Import the fresh data without Source Namespace Prefix in the Log tab.
“Copy” and “Paste Formulas” on columns F to H from top to bottom.
The Categories Setup tab is already configured in my template. But don’t hesitate to double-check the mapping Section to Dev, Config or Admin. It’s a one-off thing to do. Once set to your liking, you’ll just have to clone your own template into a new spreadsheet to be used in a new investigation. Ping me on Twitter (@fcathala 🐸) if you need any help.
Google Sheet are free and I suggest that you keep all your old versions and always start an investigation on a new spreadsheet rather than overwriting an old one.
This year again, I was pleased to be accepted as a speaker at London’s Calling (Europe’s largest community-led event for Salesforce professionals) on February the 10th, 2017.
After last year’s talk on Person Account that many of you still mention to me, I thought I would come back with another return on experience: Lightning migration projects.
A strategic move
We’ve done a few of these projects where Lightning is positioned to address a particular need (mobile roll-out) or is the cherry on the cake of a process re-engineering project. It’s rarely the case (read “never so far”) that a customer would contract us for the sole purpose of migrating to Lightning. Still, there’s a strategic reason why a CIO would do so: it’s a common interest shared between the customer and the vendor which makes it a particularly good deal.
For the customer, migrating to Lightning means moving to the fast lane. Yes, you can still progress in the slow lane (Classic) but isn’t it the role of a CIO to provide the best tools to the business (Lightning)?
For Salesforce, Lightning simplifies the engineering team’s life when it comes to improving the user experience. As a result, more goodness is coming out of the Lightning garage than the Classic one.
A faster way to configure
Another significant benefit of Lightning is the change in configuration paradigm. Designing a solution used to be the matter of two options: declarative vs. programmatic. Well, there’s now a new kid on the block, it’s called componentization and it’s a revolution. I won’t go too much into the details, but components are these little configuration bricks, features that Salesforce doesn’t provide out-of-the-box and that you purchase from the AppExchange for Components. They bridge the gap between the frustration of declarative only and the risk of technical debt coming with programmatic.
Once you understand the big picture, you see that migrating to Lightning is a key strategic move. So much so, that I could understand an executive decision to switch over.
⚠ Wait! There’s a problem. Although Lightning has been around since Winter ’16, it’s still work in progress and is far from being completed. So, you can’t turn the tap on just because it make sense, as you could, in fact, break things!
Suggestions for your rollout
And that’s where my presentation kicks-in. In the below slides, I share resources to identify when is a good time to move to Lightning and how to do it.
I thought I would highlight one side of the project which is often neglected, point 8 above: change management.
On the same day I was presenting at London’s Calling 2017, I attended a session titled “Tackling the ‘We’ve always done it this way’” by the excellent Louise Lockie. I suggest that you check her presentation since correctly managing change is key in any Lightning migrations.
Have a think about it:
Your users are not as passionate about Salesforce as you are.
Your users are not (yet) as excited by Lightning as you are.
Your users are about to have their habits changed by the new UI.
Your users will need to relearn how to do things they’ve done for years on Classic.
A successful Lightning migration project is about 50% technical considerations and 50% change management.
I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.
I recently bumped into a few clients who weren’t sure about what was going on with this TLS 1.0 thing. So, I thought I would write a recap and collate the best resource available online, all in one post. Hopefully, this can help you communicate with your customers or stakeholders too.
❓ What’s happening?
Salesforce is about to upgrade its servers and enforce the use of a new encryption protocol. Failure to changing to the same protocol on the client side will lead to service disruption.
📅 When is it happening?
~~Saturday, March the 4th 2017~~
~~Saturday, July the 22nd 2017 (cutover date recently postponed by Salesforce)~~ It’s now done and over…
🔎 Where is this happening?
The risk of using the wrong encryption method exists in all areas of Salesforce making use of a network connection. A Visualforce page pulling some data from a custom object is not in scope. I have segmented these areas of concern into 4 categories:
Access to the application
Make sure that the browser you are using supports and is configured to use TLS 1.1. Validate that you are using the latest version of Salesforce1 on any mobile OS. Bespoke mobile apps must be adapted.
If you are using tools that communicate with Salesforce and have required you to use a setup program then, please validate with the vendor that they’re not stuck on TLS 1.0. This includes Salesforce for Outlook, DataLoader, etc…
If you are integrating Salesforce with your ERP or any system in your IT landscape, make sure that the data flows are encrypted using TLS 1.1. Integration layers (ESB, EAI) are certainly up-to-date with the latest technology but what about the little Java application that was written 5 years ago by… “someone”?
Some AppExchange rely by-design on an external set of servers for various reasons. This is typically happening when an AppExchange requires capabilities not currently available on force.com or needs access to an external source of information. Some code, in Salesforce, is calling a server somewhere and they’re having a chat. This “conversation” has to be encrypted using TLS 1.1.
You’ll get the exact list of endpoints that you should validate in Salesforce’s excellent article: “Salesforce disabling TLS 1.0“. It’s the reference on the topic!
🔨 How do I do it?
First, you should download and run my report (https://login.salesforce.com/packaging/installPackage.apexp?p0=04t0Y000000JwLn) to identify who, in your org, is still connecting with TLS 1.0. This will address point 1, 2 and most of point 3 (ESB using a connector will be spotted) above.
For the integration points, you should get a developer to trace the Apex classes making use of web services then reverse engineer them if, as I suspect, you too have lost the documentation.
For the AppExchange, list them and go one by to the vendor online specs. If you’re lucky, you should get a nice TLS support statement. Even better, You can have a look at Rupert Barrow‘s list of the AppExchange known offenders (still locked on TLS 1.0).
Several years ago, I was working on a massive Salesforce roll-out for a customer whose deployment policies were constraining the team to use change sets. It was a multi-sandbox, multi-vendor environments and change sets were not ideal, to say the least. As it happens, we ended up, for each version released to production, with several packages and 30+ pages of pre and post-deployment manual steps. A real nightmare, still, it gave me the opportunity to push the method to its maximum and see through it.
If you’re building a Salesforce solution making good use of standard objects and intend to ship all your configuration from sandbox to sandbox to production, get ready for a lot of manual work! Relying on manual rework generates the risk to build a great app in your Dev sandbox, get it somehow signed-off in the UAT sandbox and then screw-up the migration to Production delivering a non-functional product… Not what you’re after!
These are the usual issues people find when deploying with change sets: Continue reading →