Salesforce OrgConfessions

Hello, and welcome to another X Force Data Summit presentation. Today, I'm excited to introduce Ian Gotts. He's the CEO of elements dot cloud. But today he's gonna talk about Salesforce org confessions, and he has a lot of them.

They're horror stories and they're very interesting. Without further ado, here's Ian.

Thanks very much.

A deadly threat is choking the life out of every Salesforce org.

It's called uncontrolled agility.

From the makers of Snakes on a Plane and Fields on an Object comes Org Confessions, the movie.

This harrowing story is based on over five hundred real life events.

The very existence of the ecosystem is under threat. We have the tools to fight back.

Process mapping, organ Featuring classics like Confession one sixty nine, changing the prod login to kitties are cute dot my dot salesforce dot com.

There is hope. It doesn't have to be this way. You can be an awesome admin.

Elements dot cloud gives you the superpowers to save the day. Get it at an org near you right now.

So that was a bit of fun that our marketing team had making that movie. But behind the amusement, the jokes around or confessions, there's actually quite a serious story. And we did the root cause analysis of confessions, I think we're up to eight twenty five. And what we found were there's some common themes behind why people were having such problems implementing Salesforce.

So as we said, these were these are all anonymous. So we don't really know the backstory. But you can start to guess what some of the problems were by reading through some of those confessions. And actually, I've read all of them.

And there are basically the four key items or the four key issues around implement these horror stories are the first is very poor business analysis.

The second is not thinking about the architecture before you start building. The third is a lack of documentation, not knowing what you've built in the past, so therefore making mistakes in the future. And the fourth highest is DevOps, no formalised way of going through the implementation life cycle.

Fifth there, very poor understanding about the best way of setting up roles and permissions. And finally, it was user training. And I want to go through each one of those in turn, in very high level, at least understanding the implications of each. And I want to set them in the context of the implementation lifecycle.

But the first question people always ask is how did we get here?

So I've been a Salesforce customer since two thousand and one. So that's about nearly nineteen years now. We were one of the earliest customers back in the UK. I think there were only two people in the London office working for Salesforce when we started implementing it.

And back then it was a tactical CRM system. It was five, ten users. I think we were one of the biggest users with one hundred and fifty users in the UK and it was tactical. Roll the clock forward now to twenty nineteen or now twenty twenty.

And the investment in M and A and in the huge R and D efforts, we now have a very, very powerful strategic platform. Salesforce is no longer five users in the corner of sales. It's now the entire operation.

And what the power of Salesforce at the beginning was that it was the citizen developer, hugely agile, anybody can build anything. But what's happened is now, if we have a strategic platform, we need a far more mature implementation life cycle. So we need to get to a situation where it's not uncontrolled agility. But we want to get to a situation where we're both agile and compliant. So we can make changes at speed, but with the trust that it's not going to break anything.

And really, all confessions is this skills and tools gap. The fact that people don't know how to manage that dev cycle, there's no implementation maturity. And that's really what we're trying to put in place in terms of some of the training that I'm talking about, presentations like this, but also some of the training material that we built, and obviously working with a number of people about building the tools that are needed to fill that gap.

So let's think about that implementation methodology.

And it starts at the very front end with analyse, capturing requirements, business processes and then writing really crisp user stories that you can hand over to the developers who can then configure code and test the application that needs to be built.

In the build phase, we need some level of impact analysis and documentation of what we built because we don't build Salesforce once. It is an iterative process and therefore we're going to come back to this and need to understand what we built So when we make more changes, we don't break the org.

In the deliver phase, we need some way of loading data in a way that's safe and secure. And then we need some process for deploying and releasing the number of times that people say, Oh, will we develop in production? That's just such a bad idea. So the idea of having sandboxes and a deployment pipeline through to release.

And then finally, in the green, we've got training feedback, and then monitoring the performance of our org.

So let's look at those org confessions in the context of this implementation methodology.

One thing was interesting was I got out my I worked for Accenture before setting up elements, and before setting up Nimbus, which was the last twenty years. And when I joined Accenture, I was given, in fact, it was Anderson Consulting at the time, I was given a book called Method One, which was all about the implementation methodologies.

And that was back in nineteen eighty six-eighty seven. If I look at the methodology for implementing package systems, as they were called, then there are nineteen key activities. If I now look at that, in the light of cloud computing, only two of those activities aren't required. There are still seventeen of those nineteen are required.

So implementation methodology has been around forever. And cloud doesn't mean you don't need to do this. You absolutely need to go through these steps. Being agile means you maybe do them more quickly and actually a smaller scope, but we still need to do every activity.

So let's dive into those different org implementation issues. The first is analyse. So this capturing requirements, mapping processes, writing user stories.

So for many people out in the ecosystem, business analysis is this.

You're a just admin. What I mean by that is your admin where someone walks past your desk and says, Could you just do that? Could you just add a picklist item? Could you just add a new report type?

Could you just add? And if you have no way of pushing back? The answer is yes, I'll do that. Even though your body is screaming, No, I don't want to do that.

That's going to screw the org up, but you have no way of pushing back.

So typically, you end up with some feedback, the statement of work suggestions, some random wishes, someone who came back from Dreamforce and said, I think we need Einstein, and a few gems in there. And what happens is if you're just admin, you end up configuring and coding and testing it, when really what you ought to be doing is putting in the steps of understanding the requirements, and you will end up with those raw requirements, which then need to be validated.

So your job is, from a requirements perspective is capture, triage, prioritise. By triage, what I mean is some of these requirements just don't make sense. Some of them are too high level, some of them are too low level. And the only way to start to validate them and understand the requirements that are missing is start to map your processes. Once you're happy with those, you've got a set of requirements, you can then write user stories. And it's the user stories of the handoff into your development team with the process maps as the context.

So let me just go very quickly through what I I talk about process mapping. Many of you out there have said, Oh, I know how to map processes, I write flowcharts.

So what I want to show you is something which essentially is an upgrade to flowcharts.

So it's a very simple mapping approach called UPN, Universal Process Notation. It's been around about twenty years. It's not proprietary to any application or any tool set. You can use pen, paper, Visio, PowerPoint, elements dot cloud, boost chart, whatever.

But some simple principles here around the way we're doing these UPN diagrams.

And it's driven by the fact that now people have a relatively short attention span. Everybody's online. So you need to be able to see this stuff on a screen. And also the content we're creating is not just for our use in terms of designing a process, so we can build an application. But this content can also be the material that ends up being the training content for the end users. And if you're highly regulated, this is what the regulators look at confirming this is how you operate.

So let's just look at just the guts of how this works. First of all, every process step starts with a verb, resolve, request, test, analyse.

Every process must have lines going in and out with text on it. So it comes in with a non sales issue and the result comes out with resolved or new issue.

Where are the diamonds? Well, you don't need diamonds, that box called resolve technical support request has two lines coming out. And the decision about how you resolve that technical support request may be documented in some notes that are attached, hence the paperclip. Or if there's a little corner, then you can drill down to the next level of detail.

So three things that make this different from a traditional diagram. Number one, it's you have the ability to drill down to a low level of detail. So you can keep eight or ten boxes on a screen, which makes it readable on a screen and it makes it easy for anybody to understand.

The second thing is the idea that you can have attachments. So you can attach a link to documents, a link to an image, link to a screen, link to a video. So suddenly, this is really valuable training material. And the third thing is you need some level of version control over this, because you're going to be iterating through these process diagrams.

So you want to come back to this the next time you have any requests. So someone says, Oh, we need to be able to issue returns to customers. Great. Well, let's look at this diagram and understand how we would then process a return rather than just a sales request.

So these aren't diagrams you throw away when you start the project. These are ongoing and live throughout the course of the life of the organisation.

And there's lots of material that we've been written about UPN, there are some videos that we've built in terms of how to draw these diagrams. And that they're really quick and easy to create in live workshops with end users. And it's really engaging when you're working with an end user on a diagram like this, than taking notes going away, writing something up and coming back.

In terms of user stories, there is a standard format the whole industry uses and the user story is as a sales user, I want to add an opportunity so that I can sell to non US customers. And for any requirement there may be multiple user stories.

So that was business analysis. In the interest of time, let's keep going.

The next thing which I see very poorly done is architecture.

Architecture, if you think about a house, if you don't build the foundations correctly, if you don't think about building a two storey house and forget to put the stairs in, or don't put the electrics in, you're pretty much screwed in terms of any ongoing work.

And that is also true for architecture when you start thinking about Salesforce. If you haven't thought through the data model about how you want to operate, then it's gonna be very hard to unpick that and rebuild it.

So I play bass in a rock band. And we want to use Salesforce to start to track how we got gigs.

So we could track the venues, track our fans. And we started, we could have just dived in and said, right, we're going to build a gig object and we're going build a venue object and a band object. It wasn't till we started digging into it a bit further, we realized that the booking managers move between venues. So the booking manager needs to be a separate object.

We also realised for gigs we were working, we were doing, maybe we open for another band. So we need another object called band where we had joint gigs.

So the data model associated with the process uncovered a real understanding about what we needed to build.

If we just launched in building objects without thinking about the architecture, we would have suddenly found that the booking manager was associated with a venue. And then we'd have to try and unpick that somehow.

So again, it feels like a lot of effort before we start building in terms of analysis and architecture. But this is fundamental to making sure that you can go faster when you get to the build phase.

So let's talk about build.

The issue around build is a lack of documentation. And people say to me, well, I'm too busy to get documentation done.

And my comment is that you're too busy not to.

Whilst it may feel like you're going faster on this particular project, when you come back the next time and start to make changes to those record types or Apex classes or objects, and then you find that you're doing investigation for hours on end to try and work out what an object does, or worse, you go and implement and then you break something and then you have all the scrabbling to try and unpick it, you'll suddenly realise the value of documentation.

Now I get it that nobody wants to document anything. So we need to make it as easy as possible for anyone to document their org.

And fortunately, there are some tools that help us do that inside the Salesforce world.

But the heart of all documentation is a metadata dictionary. That is a listing of every metadata item in your org, Apex classes, objects, fields, Lightning pages, managed packages, permission sets. So every bit of metadata in a data dictionary.

And there is the metadata API inside Salesforce, which allows you to pull all that metadata out. But it also then means you can do some analysis on it. So you can start to build a picture, say in this case, on the screenshot, we we're down at an object level. So we have an object called project. And we can start to build a picture here about how many approval processes, how many custom fields, we can even do some analysis on how many fields have got data.

So documentation doesn't have to be just the documentation you put in.

There's enough method coming out of the metadata API. And now the dependency API, we can do a hell of a lot of work in terms of building some of that documentation for you to make that impact analysis a lot easier.

So if I take an example down at a field level, you can see here the budget field, but on the right hand side, we're now starting to look at whether the field is populated by record type.

So I can see the operations record site has got no data at all. So it's a question whether this field either it should be populated, or whether we don't need it on that page layout.

And then you can see a bit lower down, we're identifying where this field is used. So it's used in the five page layouts, three process builder workflows and so on. So the ability to start to do a tonne of analysis for you makes life easier rather than having to document anything.

And with a new dependency API, we can start to build this exploded view. So you see the impact of making a change in this case to an object, which is touched by all those different metadata items. And you can keep on expanding that tree out and out and out. And very powerful in terms of understanding the impact of making a change to a particular object.

So when people think about documentation that they go, alright, I'm going to build an Excel spreadsheet, I've got to create a big word document that no one will ever read. There are some more sophisticated approaches.

We don't care what you build it in. But you do need a metadata dictionary, and you need some mechanisms for keeping it up to date.

Moving on to deliver. So we've now built something where it's tested, it's ready to deliver.

Again, you need a formal process for how you get through sandbox, sandbox UAT through to production.

Again, all confessions, we see so many examples of people developing straight into production.

And that is again, five users tactical solution in the corner, that's probably not an issue. But we're now building systems which are used by hundreds or thousands of users. And therefore we need to put in place a more sophisticated or more mature CICD process. And again, Salesforce has got change sets, but there are other products out there which will start to give a little bit more assistance in terms of building that deploy release process.

Again, fundamental step, which is how do we get from our dev environments into production?

And the last step we see there is in terms of training and people talk about we need to make sure we have decent training material, we all need to train users on the new releases that we're producing, but the new releases that are coming out from Salesforce.

And training, I think is the wrong answer. People aren't after training, people are after user adoption, what they want to see is that the systems that they are building are being well adopted.

And the reason that I've highlighted all these other boxes for user adoption is because if you build what users want, not what they thought they might need, ie you do decent business analysis, you are more likely to get user adoption because you built what they wanted. So therefore, great user adoption starts at the beginning with great analysis.

And then in terms of well documented orgs, and then some of that documentation you've got can then be delivered as training material. The fact that you're explaining or documenting why you built that project object may be useful for an end user to understand how they should be using that object, or the documentation about a particular field about the way the validation rule works, is useful training material for the end user. So you should be able to surface that to the end user.

So these aren't skills that we just get born with. These are learned skills.

Trailhead clearly is a huge resource around for understanding how to do DevOps, how to set up permissions.

There is a lack of training at the moment around business analysis.

There's some architecture work that's being done at the moment.

And lack of around documentation, there's very little training. So at elements, we've built some training material, you can get to it, it's free. It's written in the trailhead style. It's at train. Elements. Cloud. And there you'll find the whole life cycle explained sections on business analysis, on architecture, on impact analysis and documentation and on training.

And a lot of that content we've given to the Trailhead team and they're looking at how they can start to incorporate some of that inside Trailhead, which is obviously really important to develop out that resource.

So I think the fundamental message here is you need to take control. If you don't start controlling your in terms of analysis, build, deliver and then operate. Your org will control you, which means that you will be in a stressful role, constantly chasing a tail and becoming a just admin. Yes, I can just do that. What you need to do is take a step back and build up these skills of is particularly in business analysis to make sure that you're controlling your org rather than it is controlling you. So now is your chance to take control.

So happy to have any questions. If not, please follow me on Twitter at ian gots or ping me an email at ian elements. Cloud.

Thank you, Ian.

I love the whole org confessions thing and I love your tool. I mean, I'm not, this isn't a sales pitch, but having managed a Salesforce in my old job, my goodness, the need for good integrated documentation is huge. And some of the other presentations at this conference that we've recorded already certainly could use documentation, especially for the integration task. One of the presenters was talking about going from integration tasks where he took from one Salesforce org and pushed into another Salesforce org. He was going through his step by step and he's, of course you document and asked him, he had some tool he like, well, you know, usually Excel or whatever. Well, it's a pain in the butt, you know, and anything that's a pain in the butt people tell him not to do even no matter how important it is. So that's my pitch for your product.

One of the things I wanted to drill in on a bit, do you find that deployment is a source of a lot of confessions? Because I always found Salesforce deployment, I know there are tools to do it, but it's really compared to, you know, have a software development background and you know, when we deploy from test production, you know, so easy to automate that yet, you know, change set, even if you have to do change sets in a database, you know, you write up your database code that's gonna, you know, alterations of the database and so forth. Salesforce seem to make that really hard.

I think the issue is, first of all, that people don't understand that they even need a deployment pipeline. I think if you go back to the very first chart I showed with maturity, Salesforce has created this massive opportunity for people from any walk of life to be able to transfer and change career, which is fantastic. And they built Trailhead to help people understand how to use Salesforce.

But many of those people are not coming from a systems background like you or I are. And therefore they're arriving and they're not even understanding there's an implementation methodology. So it's not that they don't understand how to use the tools. They don't understand the implications of this.

So I think there's some foundational training that's often missed, which is what we're trying to put in place to help someone who's never involved in systems before, maybe they were a forklift truck driver, maybe they're a beautician, maybe they're now a mom that's come back into the workplace. And they're seeing Salesforce as an opportunity is those foundational skills. So the conversation we just had about deployment and production versus sandbox. For many people, of the confessions are, I didn't even know a sandbox existed.

So I think we've got some base skills that we need to get people up to speed on in terms of understanding how to get through that implementation life cycle.

And that's where I think some of the confessions are coming from, which is, if I think back to one, oh, we do all our development and production because that's where the data is.

It's that level of issue that I think we still need to overcome.

Right, I think budget's involved too sometimes with that, that having a full sandbox is expensive and you can't, A, if you don't know you need it, you can't justify it and B, even if you know that you need it, you still have other things that are more pressing needs, right?

Yeah, I mean, wrote an article a while ago called Free Not Free.

And it's interesting, it wasn't a picture you have to buy products, but it was about you need to understand that free isn't free. There is always a cost associated with it. If I use Excel for building my data dictionary, I then have the cost of managing it. If I use, if I simply spit all my backups back into a CSV file, there is a cost associated with how I do that restore.

So the article was saying, think about all the costs which are time, there's some financial costs, so there may be some security or risk costs associated with using the solution you've chosen. So you need to weigh all those up so you can build a business case. And the answer might be still, the best way of doing it is you use this free utility. Fantastic, but at least you've gone into it with your eyes open, rather than the attitude of I can't do this, I haven't got any money, I have to use free things.

And then actually costs you longer than a lot more in the long run. So I think it's going in. And as you said, building a business case for why these things are important.

Yeah, exactly. Freeze only.

The other thing is, you know, only free if your time is worth nothing, right?

That catches. Yeah.

And it's not just your time, it's also your reputation.

So your system goes down or you lose customer data because one of the situations was one of the confessions, a consultant loaded another client's data into client twos org.

Right, so I've now got just the data implications of someone loading customer one's data, client one's data into client two's org.

And then how do you unpick all that? So yeah, it's not just the costs associated with it.

There's the reputational issues, the downtime for all your teams sitting there going, well, we can't use Salesforce because we need to unpick the data. So there were some hidden costs as well.

So UPN is something that is built into your product. Is that that's your standard for process documentation?

Yes, that's right. So UPN is a standard notation. We've built an application which supports it. So I mean, you could do UPN with pen and paper. Quite often do when we're sketching things out.

So it's a principle rather than a proprietary technique that our application works on. So yes, so I would encourage people to look at how the principles of UPN because it simplifies the whole way of drawing process diagrams rather than getting engaged in flowcharts or UML diagrams or BPMN with all these different shapes.

And at your training site, do you have some basic introductions to UPN?

Absolutely. So if you go to train. Elements. Cloud, there's a trailhead trail, I can't call it trailhead, there's a training site in the trailhead style.

And there's one on business analysis. And that covers how to capture requirements. But there's a whole section on the process mapping. And there's a video by a guy called Walter, who's one of our customer success guys on how to run virtual process mapping sessions as well.

So thinking about the new world where a lot more of us are now operating remotely, it's slightly more challenging running a process mapping workshop.

We've got about twenty years experience. So Walter's created a video there for doing virtual process mapping.

Ian, thank you so much and appreciate your time and efforts and look forward to looking, spending more time looking at elements dot cloud.

Thank you so much.

‍