Trust the Process

Process Adherence in Low/No Available License Orgs

As a Salesforce ISV, we see all manner of organization structures - and as a high-performance delivery team, we’ve carefully honed and refined our change management and delivery processes.  We recently worked in an org that had only a single available license in their Production environment, and the temptation for the entire team to operate using that single license was certainly present.  However, while we don’t view our tried and true processes to be completely inflexible - we do understand their underlying value and benefit.

in this article, I want to detail a few simple approaches on how we keep the integrity of our workflow, despite the challenge of negotiating the technical landscape of a potentially shared license.

But first, let’s do a quick rundown of our process, and talk about the reason behind it.  Our best practice is for each member of the delivery team to have and work from a developer-type sandbox.  Once completed, coded work is managed with version control (Github) and then deployed to the QA environment.  Those changes are then deployed from the repository’s master branch to the QA environment with our continuous integration tool.  Declarative changes are similarly deployed from the originating sandbox to the QA environment.

While there is a bit more that goes on beyond what I’ve described, that is the foundation of how we manage our work.  It allows each team member to develop independently on their own work, and prevents issues of inadvertently overwriting others’ changes.  The cornerstone to the entire process though, is the assignment of discrete sandboxes for each member. Without that, every other component of the pipeline is jeopardized.

The availability of a single Salesforce license in the Production environment does present a hiccup in that initialization, however.

Quick Audit of Existing Licenses and Usage.  The first (but not necessarily easiest) step to take is to examine how the existing licenses are being used.  In the project I mentioned above - there we a number of licenses that were redundant, including several that appeared to be used only for the purposes of integrating Salesforce with other third-party systems.  Unless there is a compelling business case to do otherwise - we always recommend that these API-users be consolidated under a single API-only User record.

The easiest way to accomplish this (from the Salesforce end of the integrations) is to clone the System Administrator Profile, and name it “API”.  Afterwards, change the Password Policies, changing the value of the “User passwords expire in” to “Never expires”. This prevents the interruption of any integrations due to password expiration.

A secondary consideration for the audit is finding User records having the same Email address.  While it is not entirely impossible to have a valid use-case for a person to maintain more than a single User record - it also is worth investigating.  If you want to execute a SOQL query to find email addresses that are shared across User records, you can execute the following as an anonymous apex script:

List<AggregateResult> aggregateResults = \[

SELECT Email, COUNT(Id)

FROM User GROUP BY Email HAVING COUNT(Id) > 1

\];

  

for(AggregateResult result : aggregateResults) {

System.debug('Finding duplicate names: ' + result.get('Email'));

}

  

The second approach is to manage the diversity of delivery team User records in the pre-production environments.  To reiterate from earlier, the most fundamental tenets of my team’s process is that we will not develop in a shared environment.  As long as at least one license is available in the Production environment, then we can spin up the number of sandboxes needed for each team member, including QA and UAT environments), then deactivate as many business users as needed in each environment to insure that the delivery team can work.

Alternatively, instead of creating the single Production User record using a specific individual’s email address, consider using a distribution email that the delivery team can monitor.  Team members would still change that email address in their sandboxes, but it does allow for easier access in the integration pre-production and production environments.

View more blogs and tutorials about Salesforce B2B Commerce Cloud

Learn more about our Salesforce B2B Commerce Cloud work

For thought leadership on B2B Commerce,

please click here for blogs and here for video