The most common task of any Salesforce implementation is the creation of user accounts. All projects need users! It can be as simple as inputting a few users from the UI or loading one or several CSV files dealing with parent-child relationships. The user object has a particular place in Salesforce between metadata and real data. In this post, I’m going to talk about users import and configuration in an org where you’ve already deployed the security components profiles, permission sets, roles, public groups and queues.Continue reading
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.
The software has been tested by many users and customers before you.
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:
- All Salesforce tenants run on the latest version.
- There are three new releases every year.
- Salesforce is quite an innovative company.
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.
Related Posts & Resources
- Forbes: Custom software vs. canned solutions
- CIO.com: When to build or buy enterprise software
- Salesforce: The power of low code
I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.
Several times in my career, I came across situations where my client wanted to take the driving seat of an implementation after a brief introduction to the basics of Salesforce configuration. Maybe they looked over the shoulder of a consultant creating a report or a page layout. “Oh yes, I get it it’s a bit like such and such language” I still hear them shouting…
One of my friends, was telling me about this Sales Cloud project originally meant to be declarative-only but the customer was feeling strongly about the implementation of a lookup field which should look like a picklist field enhanced with typeahead capability.
The team didn’t have the exact skills required, but under the customer’s pressure, one consultant was assigned the task to implement a typeahead picklist pulling its data from a custom object. The development was slow. The testing reported quite a few problems which in turn were slow to be fixed. The client was also squeezing in nice-to-have on top of bug-fixes. The project ended-up delayed and way over budget for a picklist which, quite frankly, could have been delivered as a standard lookup at no added cost. For my friend’s company the project was a total disaster.
When implementing Salesforce at a customer you need to make sure that users’ inputs won’t derail the project. It’s one thing to leave the door open to feedbacks and suggestions but it’s another thing to accept everything because it’s coming from the customer.
In consulting, it’s not the vendor working FOR the customer, it’s the vendor AND the customer working FOR the project.
The project is an entity in itself with a budget, a timeline and a scope.
##The Salesforce Police
The vendor and the customer must work together to keep the balance right. Because the vendor is the one bringing project expertise to the table, he is the one expected to agitate a red flag when the client’s changes in requirements are becoming a risk to the project. As a Salesforce expert, you need to make sure that best practices are followed, declarative comes before programmatic, you don’t reinvent the wheel, your solution is compatible with the next releases… You are the Salesforce police!
##Avoiding Scope Creep
To avoid your project to go pear shape as in the previous example, you may want to consider the following advices:
End of Sprint Demo
This is the place where most of the scope creep happens. Because there’s still, in theory, plenty of budget in this phase of the project there’s no feeling of financial pressure, and there’s tendency is to accept change requests with the hope that they will be absorbed during the remaining part of the build. Also, be conscious that you are pulling the curtain on unfinished software. The chances are that your audience can’t visualise the solution as you do and potentially ask for useless changes.
- Be budget conscious from start to finish. Your team has a fixed capacity: More effort will require more resources or more time and anyhow more budget.
- Avoid demoing half-baked features as this is going to waste everybody’s time and bring low-quality feedback.
User Acceptance Testing
This is another part of the project that can generate an important increase in scope. Key users may be change averse, they may want their brand new system to behave exactely like the old one. The idea of the UAT is to get a feel for adoption before go-live fixing bugs and addressing show-stoppers. It’s not about going back to the drawing board because Joe Blogg doesn’t like your solution.
- Always clearly state the goal and limits of UAT.
- Obviously, it’s down to the stakeholders to deal with people issues internally.
User Designed Solution
Some users will find interest in this refreshing new project and drop funky requirements as a way to enlighten their day. They may ask you features that exist in other web applications like Facebook or Instagram. Please remember that ultimately you will be the one with the neck on the table when your Facebook like typeahead doubles the cost of the build phase.
- Key users involvement in agile projects is about gathering business requirements then validating that the solution delivers the expected business outcome. It’s not about swapping seats.
- Listen to implementation preferences but make the final decision design based on your experience.
New Features Requests
Accepting new functionality requests up until UAT is totally fine. It’s one of the core benefits of agile methodologies. But this should not lead to scope creep.
*Always position a conversation on new feature requirement in the context of project success and ask what the trade-off is: increase in budget, delayed delivery or dropping another feature.
Never Ending Refinements
To be deployed to production in time your solution must first reach code-freeze. In the picklist story, the customer was asking for numerous non-functional refinements, pixel level cosmetics. Because the work started without a crystal clear description of the requirement, many iterations were required before a satisfactory result.
- Make sure that any piece of work is clearly described and understood by all parts. Associate each user story to acceptance criteria. Avoid subjective description like “The picklist must look great”. From the list of acceptance criteria, you should be able to write the project’s Definition Of Done. Get an early sign-off.
Hopefully these few advices will help you avoid getting into budget troubles while keeping your customer happy and your project successful.
I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.
With Winter ’17, Salesforce added the possibility to display your company’s logo on the top banner of any custom app in the Lightning experience. I thought I would take the opportunity and write a post on how to best handle this logo business for both Lightning and Classic.
You can only add your logo to a Lightning App. That’s right, apps can be of either LEX or Classic type! You can’t reuse an existing Classic app.
==Navigate to the App Manager== in the Setup pages, you can either create a new app from scratch (1) or upgrade an existing Classic app (2).
From the Edit screen, upload your company logo (3).
The logo file should be of one of the usual formats (jpg, png, bmp or non-animated gif). The size must not exceed 44 x 44 pixels. If you provide a bigger or non-square image Salesforce will make it fit… I suggest you stay in control of the look and feel by respecting these limits. Also, note that the image is positioned quite close to the browser’s edge…
For Lightning, I recommend to always upload an image sized to 44 x 44, including a 2 pixels top padding.
Also, don’t set any margin on the left or the logo wouldn’t align properly with the rest of the UI.
Click Save and Done and this is it. It’s quite simple when you know where to go…
The good news is that because the Lightning top banner background is white, you don’t need to fiddle with transparency as it’s the case for the Classic UI.
In Classic, you’ll need to store the logo somewhere and in a specific way before being able to add it to your app. In this respect, it’s a bit more cumbersome than with Lightning, still not a big deal as you’ll see.
First of all, you need to locate the Documents tab which, unfortunately, can’t be found in any standard app. Click on the “+” tab (1) and select the Documents tab (2).
You can either create a new folder for documents which are associated with your app or just use your “Personal Documents” folder. I go with the simple option in this case (3).
Press Go, then the “New Document” button.
Give the document record a name to locate it easily and ==make sure that you tick the “Externally Available Image” checkbox== (4). Then load the logo file (5).
In Classic my recommendation is to keep the image file to its maximum of 55 pixels with a top padding of 5 pixels. You can use any length up to 300 pixels but make sure your file is not bigger than 20KB. Always use a tranparent background.
In Setup, navigate to “Apps”. Select the custom app which will receive a new logo. Then from the Edit page click on “Insert an Image” (6) and change the logo to the one you just uploaded in Documents.
And, here’s the result!
- Nitin Gupta: Create App in Lightning Experience
I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.
I have been lucky enough to be invited to present at the first London’s Calling (Europe’s largest community-led event for Salesforce professionals) on February the 5th, 2016.
I chose a topic which meant a lot to me because I’ve done quite a lot of B2C implementations: Salesforce Person Account. Unfortunately, the presentation didn’t exactly go to plan as my PC crashed when I plugged in the projector. As a result, I didn’t cover the whole talk. So, if you were in the audience and felt left out or if you didn’t manage to join us on the day, this post is for you!
You can refer to the supporting slides that I’m sharing below.
Person Account issue
Person Account, or PA, in short, is the way to configure Salesforce to make it work for B2C users. It’s safe to say that PA doesn’t get much love in the community. Many consultants and administrators are full of bad stories explaining why you shouldn’t use it! That’s a bold statement considering that PA is a standard feature of Salesforce. While I was preparing for my talk, I searched for complaints on blogs and forums with the intention to propose workarounds for each of them. Well, I’m pleased to report that I haven’t found many road blocks that are still valid today. Most of the issues discussed online have now been fixed or are on the roadmap.
Here is the learning:
Old posts are not updated, and issues from the past can be fixed today. Don’t believe old blogs post and always test for yourself.
It doesn’t mean that Person Account doesn’t come with annoyances and complexities. I can even see one particular issue which can become a show-stopper at times but as a Salesforce administrator, architect, consultant you shouldn’t base your design choices on rumours, especially for such a critical part of CRM systems as the customer data model. Please, think twice before discarding PA as the way to model consumers.
So, for instance, one of these rumours is that PA doesn’t support cross-objects formulas. It may have been true several years ago but I can tell you that this is now fully supported…
In fact, I believe that Person Account real issue is that Salesforce ships new features as early as possible without waiting until they support both Business AND Person Account. It’s a shame as it makes PA look like a second-class citizen whereas it’s in fact a very clever part of Salesforce (see slides 6 to 8 below on backward compatibility).
So, in the end, it’s a waiting game. Some features are released without Person Account support and we know that at one point they will be improved for PA. It can be frustrating but this also applies to any software: you must design with what’s available at one time.
Mind the fake problems
One recent example of delayed delivery is Lightning Experience. In Winter ’16 you cannot have both PA and LEX enabled on the same org at the same time. Spring ’16 will fix this albeit with quite a few caveats in the way PA is supported and the following release will improve PA support on LEX. At the end of the day, Lightning Experience is not that critical to any implementation. Is it me or we’ve been designing quite a few powerful solutions in Salesforce Classic up until now? So, I guess we can wait for a few releases before making the most of Lightning.
Duplicate Management in another capability which doesn’t still support PA. Good news is that there are some (free) AppExchange to fill the gap. The thing is that deduping in a B2C multi-channels world to get a single view of consumers can be quite a difficult exercise depending on how you define duplicates: do you want to match consumers reaching you via phone call with their online identity on social networks? This can be a complicated requirement needing more than what the standard feature would deliver.
The downside of Person Account
Still, there are some problems with Person Account…
The main one, in my opinion, is linked to its architecture (1 pair of Account + Contact record per consumer). Using PA means that you are doubling the data storage required to manage your customers. If your customer base is in the millions, then this can get you to hit the storage limit and is the show-stopper I was referring to earlier. Good news is, this double count is on the roadmap to be removed! The data structure will remain the same, but Salesforce will only charge for 1 record (2 KB) “WHEN IsPersonAccount = TRUE”.
Person Account alternatives
There are options on the table to avoid the use of Person Account. Again, I would recommend to stick to the standard and preserve the capability to extend the first version of your solution in the future. But, if after carefully considering your design criteria, you come to the conclusion that PA is not for you then you could use one of my preferred alternatives:
- Bucket Model: slide 20 below
- Household Model: slide 21 below
- Custom Object: slide 23 below
In the pipe
Salesforce is always improving PA and here is what they have in mind. Please do not make any purchase decision based on the list below (“safe harbor”):
- Full Lightning Experience Support
- Eliminate Double Storage Count
- Admin Enable/Disable PA
- Duplicate Management
- Insight for PA
- New Data Import Wizard
- PA as Shared Contacts
The presentation I’m sharing above includes quite a few links that I suggest you follow to get a deeper insight into Person Account.
So, to summarise, I think that Person Account is a sitting duck which doesn’t deserve all the complaints I hear here and there. It has evolved quite a lot since Winter ’07 and, hopefully, you’re now willing to give it a second chance.
I was discussing with my team members, reviewing a part of a Salesforce solution we were implementing at one of our biggest customers when it happened to be Paul’s turn… I asked, “So, Paul, can you take me through your design please?”. “Sure” said Paul, “I’ve been working on User Story #US240 and have applied the usual best practices”. I was expecting a little more details considering that I was supposed to sign-off the solution design in the name of my team but Paul sounded like he was finished. “And…” I asked. “And that’s it” said Paul, “Just applied the BP’s, you know…”. I wasn’t happy and explained to Paul that “his” BP’s won’t cut it for me. He understood and drilled down into more details his design justifying his choices.
The thing is that, in consultancy, “best practices” have turned into sacrosanct tools used to justify the added value we are selling to our customers. Because we, as a company, have done what the customer wants times and times already, we’ve supposedly collected a set of best practices which make us the customer safe option. And that’s it, don’t go against best practices or you’re in trouble! Now, I have nothing against the concept itself. There are, effectively, patterns that consultants regularly find at different customers and which can be addressed using similar, road-tested, solutions. What I’m saying though is that best practices are powerful tools which should be used with caution. Here are a few suggestions:
- Best Practices Are Not Anonymous
All serious source of information come with a reputable origin. If you can’t track where a Best Practice is coming from then consider it as suspicious and act accordingly.
If software vendors seem like a good source because they know their products better than everybody else, be careful to avoid “business development initiatives”. I’ve seen in the past, vendors recommending design choices leading to a heavy increase in licenses count…
Innovation Wins Over Best Practices
The fact that an implementation method has proven to be successful time and time again turning into a best practice is good to know. But it shouldn’t prevent you from exploring better alternatives.
Don’t re-invent the wheel, but feel free to improve it. Your customers will appreciate…
- Best Practices Are Context Sensitive
Best Practices have a context and one working for a customer based in New-York won’t necessarily be applicable to a similar customer in London. Clients have got more differences than their industry and this need to be recognised. For this reason, your best practice must come with a justification (why is this a best practice?) and a history of successful applications. This will help the decision to use a best practice or to go the innovation route.
Best Practices have an expiration date
What was true yesterday, may not be true today. Technology improves fast, as we all know. So, what used to be the best way to do something may now be deprecated by a new feature. So again, you need to associate some extra information to any best practice: it’s dependencies. When all dependencies have gone, then the BP isn’t valid any longer, and you need to find another way.
Best Practices are centrally stored in your KB
What? You don’t have a team Knowledge Base? Your consultants memorise their best practices as they can? Then, you can’t sell “Best Practices”. ==Many consultancies pretend they deliver a value added they don’t have==. Best practices should be written with contextual information and stored in a searchable database (or wiki), accessible to all consultants.
See below an example of a Best Practice record:
Your best practice KB entry may look like the one above or any variant you may think of. The point is that to fully leverage best practices you need to:
- Store them somewhere
- Understand them inside-out
- Challenge them
- Own them.
At this stage, you become a Best Practice Master and you can comfortably decide to use them in your designs or “invent a better wheel”…
If you decide to build a best practices knowledge base, then you’ll find the documents below very useful as a starting point:
- Best Practices for Implementation Consultant
- Best Practices for Administrator
- Best Practices for Sales Manager
- Best Practices for Marketing Manager
What’s happening when you press “Save” on a record in Salesforce? A transaction is triggered and Salesforce will orchestrate all events happening afterwards in a specific way. It is critical to understand the following things if you want to implement a lot of business logic or if you mix programmatic and declarative:
- There is known sequence of components activated
- The components of the same type are executed in a random order
Which basically means that if you have dozens of workflow rules, as it’s often the case in old orgs, you cannot control which one will run first and set a context for the following rules. Same for triggers and it’s the origin of the design pattern “one trigger per object” (also read this other post from Bob Buzzard). It’s not possible to apply this approach to workflow rules but thankfully you can with process builder as demonstrated in this post by David Litton. Note that, nowadays you can implement one process builder that will call invokable process builders rather than piling all the business logic into a single component.
Take for example a Case object configured with escalation rules, adding a set of validation rules and one or several workflow rules. Which value will the validation rule validate? The one input by the user or the one overridden by escalation rule or the one set by one the workflow rules? You need to understand the Order Of Execution…
Below is the simplified sequence to remember:
- 😈 System validation rules
- ⏪ Apex before triggers
- ✔️ Custom validation rules
- ⏩ Apex after triggers
- 👨👩 Assignment rules
- ♻️ Auto-response rules
- 🚀 Workflow rules
- 🍄 Process
- 📟 Escalation rules
- 🔎 Roll-up summary fields
I have listed some great resources to dig deeper into the subject.
Related Posts & Resources
- Salesforce: Apex Developer Guide
- Alba Rivas: Triggers and order of execution
- Johan Yu: Validation rule in workflow and process builder
- Ashish Agarwal: Order of execution (rules, triggers, etc)
- Brian Cline: Salesforce order of execution
- Alba Rivas: Visualforce order of execution 1
- Forcetalks: Order of execution in Salesforce
I hope you enjoyed this post. Don’t hesitate to leave a comment below or ping me on Twitter.