Salesforce Solution Design: Success is a Team Sport

I think I speak for many admins and consultants when I say that thinking about a Salesforce solution can be harder than configuring it. By the time you’ve finished gathering requirements, mapping processes and mocking things up, the solution you plan to build is nicely taking shape in your brain.

The big question is: how can you be certain that you’ve considered EVERYTHING?

After an intensive period of workshops, meetings and presentations, much of what you’ve seen, discussed and thought of is theoretical at this stage; it’s easy to befuddle yourself in the midst of information overload. As consultants, we have to understand as much as possible about an organisation within a couple of weeks, whereas it might take an internal business analyst months to learn the same amount.

As a solution architect, this forms the foundation of what I do for a living. Solution architects take business requirements and translate them into working solutions. What makes it a different job is the need to balance desired outcomes with appropriate strategies and considerations for the following:

• Volumes of data
• Future growth plans
• Database performance
• Integration strategy
• Design standards
• Sharing and visibility of data
• Data model
• Permissions architecture
• Longer-term management of changes
• Authentication

…and many more.

What’s the point of a review board?

The truth is, Salesforce is so flexible, there isn’t always a right way to build a solution, and you can easily get too deeply involved and then you need a second pair of eyes. At Bluewolf, we have review boards at the end of each Design stage. They’re a fantastic way to sense-check, bounce ideas around and play back what’s in your own head to a board of your peers. Not bears.

All Solution Architects get a chance to present or sit at a Review Board. The idea is to present the key highlights of your solution to colleagues who are not working on your project. This gives them the opportunity to:

1. Raise questions
2. Challenge or agree with your approach
3. Get you thinking about things you may not have considered
4. Help you work through any points of contention in your design
5. Learn (or teach!)

In addition, it gives you the opportunity to:

1. justify or change your decisions in a safe environment
2. practice presenting your solution
3. debate on best practice techniques
4. Learn (or teach!)

It’s a great way to sense-check what’s going on in your head, whilst you’re in the thick of it all. It builds teams and trust within them. I wish I’d been doing this in my previous roles.

Recent experience

Taking a recent data model example; another SA and I couldn’t agree whether to use a standard or custom object to represent an insurance claim. There were many great arguments for and against each approach; we Chattered it out to the wider community and scoured the forums and documentation in an attempt to reach a consensus.

No matter how much we discussed it, we each had strong opinions on our own designs, so the review board was the best forum for us to take it. We agreed on an approach then, but by the time we clarified some of the customer’s requirements, we were back at square one again, debating the options and unable to really see a strong way forward.

So we called another review board; this time with a CTA!

How did we structure it?

• We started with the user story and broke it down into requirements
• Explained to them why we couldn’t agree, then presented each proposed solution.
• We listed the Pros and Cons, as well as any obstacles we expected
• When prompted, we came up with workarounds for these obstacles
• We listed any additional considerations and then we asked for feedback
• We thanked them for their time (manners!)

In the end, our reviewer couldn’t decide which one to go with, because both solutions were well-researched and equally as sensible. So we compromised, recommending a combination of standard and custom objects with a transformational business process to complement the two. This would mean any interactions would be logged as a case, and an insurance claim would be a custom object in order to enable users to search on a claim number and see the results coming back separately from all other enquiry types.

Why not involve the customer?

Why not indeed? You’d think that the right approach would be to present both options to the customer and allow them to weigh up the arguments and choose. I’d agree if you are working with a customer who has experience with Salesforce. For those who are new to it, you can risk confusing them with too much technicality, so sometimes I believe it can be appropriate to keep the debate internal and make a recommendation once you agree on the approach.

What if I’m too busy?

Yeah, I know. We’re all so busy; we’ve got deadlines to hit and other people aren’t always available, especially when you work in a fast-paced environment when you could be working on several projects at once. At Bluewolf, we make time to do it, because it’s an important quality check, but not only that – think about what you can learn from the different experiences that others bring to the table. Collaborate, embrace new ideas and you’ll find your solutions not only wow, but live for longer than you thought they would!