[00:00:00] Hello, and welcome to another X-Force Data Summit Presentation. Today, I'm excited to introduce Ian Gotts. He's the CEO of Elements.cloud, but today he's going to talk about Salesforce OrgConfessions, and he has a lot of them. They're horror stories and they're very interesting. OK, further due. Here's Ian.
[00:00:34] Thank you very much.
[trailer plays]
[00:00:46] A deadly threat is choking the life out of every Salesforce org. It's called uncontrolled agility. From the makers of Snakes on Plane and Fields on an Object comes OrgConfessions: The Movie.
[00:01:14] This harrowing story is based on over 500 real-life events.
[00:01:27] The very existence of the ecosystem is under threat.
[00:01:33] We have the tools to fight back. Process mapping, Or insights, documentation!
[00:02:00] Featuring classics like Confession 169 changing the prod login into kittiesarecute.my.salesforce.
[00:02:24] There is hope. It doesn't have to be this way.
[00:02:33] You can be an awesome admin.
[00:02:42] Elements.cloud gives you the superpowers to save the day. Get it at an org near you. Right now.
[00:03:00] 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, now it's over 800 confessions. I think we're up to 825. And what we found were some common themes behind why people were having such problems implementing Salesforce.
[00:03:28] So, as I 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 implements for these horror stories.
[00:3:47] 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.
[00:04:00] And the fourth highest is DevOps. No formalized way of going through the implementation life cycle.
[00:04:10] 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 a very high level. But at least understanding the implications of each, and I want to set them in the context of the implementation life cycle.
[00:04:31] But the first question people always ask is, how did we get here? So I've been a Salesforce customer since 2001, so that's nearly 19 years now. We were one of the earliest customers back in the UK. I think there are only two people in the London office working for Salesforce when we took on when we started implementing it. And back then, it was a tactical CRM system.
[00:04:53] It was five, 10 users. I think we will, one of the biggest users with 150 users in the UK. And it was tactical. Roll the clock forward now to 2019 or 2020, and the investment in M&A and in the huge R&D efforts, we now have a very, very powerful strategic platform. Salesforce is no longer five users in the corner of sales.
[00:05:19] 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.
[00:05:41] Well, 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 is not going to break anything. And really the org 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.
[00:05:59] 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.
[00:06:18] It starts at the very front end with analyzing, capturing requirements, mapping business processes, and then writing really crispy 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.
[00:06:40] It is an iterative process, and therefore we're going to come back to this and need to understand what we've 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, well we do that in production.
[00:07:02] That's just such a bad idea. So the idea of having [00:07:00] 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.
[00:07:22] One thing was interesting. It was, I got out my, I worked for Accenture before, setting up, elements and before setting up Nimbus, which was the last 20 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.
[00:07:43] And that was back in 1986-87. If I look at the methodology for implementing packaged systems as they were called then there were 19 key activities. If I now look at that in the light of cloud computing, only two of those activities aren't required. There were still 17 of those 19 that are required. So implementation methodology has been around forever
[00:08:07] 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 analyze.
[00:08:25] 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 you're adding in where if someone walks past her desk and says, Could you just do that? Could you just add a picklist item?
[00:08:45] Could you just add a new report site? 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 ended up with some feedback, the statement of work suggestions, some random wishes.
[00:09:05] 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, if you're just a 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.
[00:09:26] So your job is, from a requirements perspective, is capture, triage, prioritize. 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 were 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.
[00:09:46] 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 that are the handoff into your development team with the process maps as the context. So let me just go very quickly through what I, and when I talk about process mapping, many of you out there have said, Oh, well I know how to map processes.
[00:10:05] I write flow charts. So what I want to show you is something which essentially is an upgrade to flow charts. So it's a very simple mapping approach called the UPN, universal process notation. It's been around about 20 years. It is not proprietary to any application or any toolsets. You can use PenPaper, Vizio, PowerPoint Elements.
[00:10:27] There are 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.
[00:10:54] 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 to confirm that this is how you operate. So let's just look up just the guts of how this works.
[00:11:09] First of all, every process step starts with a verb, resolve, request, test, analyze. 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, now it comes out with resolved or a new issue. And people go, Where are the diamonds? Will you don't need diamonds.
[00:11:31] 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.
[00:11:52] Number one, it's, you have the ability to drill down to a low level of detail. So you can keep eight or 10 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 a document or link to an image, link to a screen, link to a video.
[00:12:15] So certainly 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.
[00:12:33] Great, well, let's look at this diagram and understand how we would then process a return rather than just a sales request. So there's not, 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 organization. And there's lots of material that we've, there's been written about UPN.
[00:12:54] There are some videos that we've built in terms of how to draw these diagrams that they're really quick and easy to use 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, rather than taking notes, going away, writing something up, and coming back.
[00:13:14] In terms of user stories, there is a standard format the whole industry uses, and a user story is as a ... sales user, I want to have an opportunity so that I can sell to non us customers, and for any requirement, they're beaten. There may be multiple user stories. So that was business analysis. In the interest of time, let's keep going.
[00:13:37] 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-story house and forget to put the stairs in, well, don't put the electrics in, you're pretty much screwed in terms of any ongoing work.
[00:13:55] 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 going to be very hard to unpick that and rebuild it. So I played bass in a rock band, and we want to use Salesforce to start to track how we got gigs.
[00:14:18] 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 to build a venue object and a band object. And it wasn't until we started digging into it a bit further, we realized that the booking managers moved between venues.
[00:14:34] So the booking manager needs to be a separate object. We also realized 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.
[00:14:52] If we just launched in building objects without thinking about the architecture, we would have suddenly found that the booking manager was associated with the 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.
[00:15:10] 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. When people say to me, Well, I'm too busy to get documentation done, my comment is that you're too busy not to. While it may feel like you're going faster on this particular project when he comes back the next time and starts to make changes to those record types or apex classes or objects.
[00:15:41] And then you find that you're Doing investigation for hours on end to try and look at what an object does, or worse, you go and implement, and then you break something and then you have all the scrubbing to try and unpick it. You'll suddenly realize the value of documentation. Now I get it that nobody wants to document anything.
[00:15:58] 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.
[00:16:23] So every bit of metadata in a, 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 have, we're down at the object level.
[00:16:44] 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 could even do some analysis on how many fields have got data. So documentation doesn't have to be just the documentation that you put in. There's enough message coming out of the metadata API and now the dependency API.
[00:17:06] 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 fine. 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.
[00:17:25] So I can see the operations record type's got no data at all. So it was a question whether this feels either it should be populated or whether we don't need it on that page lapse. 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.
[00:17:43] So the ability to start to do a ton of analysis for you is, 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.
[00:18:01] 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, they go, All right, I'm going to build an Excel spreadsheet. I've got to create a big word document than they will ever read.
[00:18:20] 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 which is tested. It's ready to deliver. Again, You need a formal process for how you get through sandbox, sandbox, UAT through to production.
[00:18:43] Again, we see so many examples of people developing straight into production. And that is again, five users, tactical solution and a call, 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, a little more, more, mature CICD process.
[00:19:07] And again, Salesforce has got changesets, but there are other products out there which will start to give a little bit more assistance in terms of building that deploy-and-release process. Again, fundamental step, which is how do we get from dev environments into production? Well, the last step we see there is in terms of training. And people talk about the, We need to make sure we have decent training material.
[00:19:33] We will need to train users on the new releases that we're producing, and 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 up being well adopted.
[00:19:52] 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. i.e., 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.
[00:20:15] And then in terms of well-documented orgs, and then some of [00:20:00] that documentation you've got can then be delivered as training material. The fact that you're explaining or documenting while you built that project object may be useful for an end-user to understand how they should be using that object. All the documentation about a particular field, about the way a validation rule works, again, is useful training material for the end-user.
[00:20:39] 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 dev ops, how to set up permissions. There is a lack of training at the moment around business analysis.
[00:21:01] 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 built some training material, you can get to it. It's free. It's written in the Trailhead style. It's at training.elements.cloud. And there, you'll find the whole life cycle explained.
[00:21:22] Sections of business analysis on architecture, on impacts in our system 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 develop that resource.
[00:21:42] So I think the fundamental message here is you need to take control. If you don't start controlling your org 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 your tail by becoming a just admin.
[00:22:05] 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 @iangotts or ping me an email at ian@elements.cloud.
[00:22:31] Thank you, Ian. I love, I love the whole, org confession thing and I love your tool. I mean, I'm not, this isn't a sales pitch, but having managed a Salesforce, Salesforce in my old job, my goodness, the need for good integrated documentation is, is huge. And some of the other presentations in this, at this conference that we've recorded already certainly could use documentation, especially for the integration tasks.
[00:23:02] One of the, one of the presenters was talking about going from an integration task where he took from one Salesforce org and pushed it into another Salesforce org. He's going through it step by step.
[00:23:13] And he's, of course, he documented it and I asked him if he had some tool he liked. He said 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 them not to do. No matter how important it is. So that's my, that's my pitch for, for your product.
[00:23:31] 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 right, but it's really compared to, you know, I have a software development background and you know, when we deploy from test to production, you know, so easy to automate that.
[00:23:50] Yet, you know, changesets. Even with, even if you have to do changesets on a database, you know, you write up your database code that's gonna, you know, alterations of the debate database and so forth. Salesforce seemed to make that really hard.
[00:24:05] I think, 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 the, with the maturity. Salesforce has created this massive opportunity for people from any, 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.
[00:24:32] 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 that 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.
[00:24:56] Maybe they were a 40 trough drop truck driver, maybe they're a beautician, maybe they are now a mum that has 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, some of the confessions are, I didn't even know sandbox existed.
[00:25:15] 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 it's, that's what I think some of the confessions are coming from, which is if I think about back to one. Oh, we do all our development and production because that's where the data is. It's that level of the issue that I think we still need to overcome.
[00:25:43] I think there's, I think budgets involved too sometimes with that. You know, having a full sandbox is expensive, and if you can't, if you don'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, you know, other things that are no more pressing, pressing needs.
[00:26:02] Yeah. I mean, I wrote an article a while ago called Free, Not Free. And it was, it wasn't a pitch about you have to buy products, but it was about you need to understand that free isn't free. There was always a cost associated with it. If I use Excel for building my data dictionary, I then have the cost of managing it.
[00:26:23] If I use, if I simply spit all my backups back into a CSV file, there was 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, there may be some security or risk costs associated with using the solution you've chosen.
[00:26:45] 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."
[00:27:03] And then actually costs you longer than the lot, but 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 were important.
[00:27:11] Yeah, exactly. Free's only... the saying is "free is only, only free if your time is worth nothing."
[00:27:22] 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, into client two's org, right? So I've now got, just the data implications of someone loading client one's data to client two's org.
[00:27:50] And then how do you unpick all that? So yeah, it's not just the cost associated with it. There's, there's the reputational issues, the downtime for having all your teams sitting there going, Well, we can't use Salesforce because we need to unpick the data. So there was some hidden costs as well.
[00:28:08] So UPN is something that is built into your product. Is that, that's your standard for process documents?
[00:28:16] 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, with pen and paper. I quite often do when we're sketching things out. So it was 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 flow charts or UML diagrams or BPMN with all these different shapes.
[00:28:54] And, and at the, at your training site, do you have some basic introductions to UPN?
[00:28:58] Absolutely. Absolutely. So if you go to train.elements.cloud, there's a, there's a Trailhead trail. I can't call it Trailhead. There's a training site in the Trailhead style. 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.
[00:29:26] So thinking about the new world where a lot more of us now operating remotely, it's slightly more challenging running up a process mapping workshop. We've got about 20 years of experience, so Walter's created a video there for doing virtual process mapping.
[00:29:42] Ian, thank you so much and appreciate your time and efforts and look forward to, looking, spending more time looking at elements.cloud.
[00:29:52] Thank you so much.