Geoffrey Bessereau is a Technical Architect over at Persistent. He founded a Discord community called SFXD which we discuss in this episode. We get into the Wiki for this community, other writings around it, and architectural and developer lessons that have been learned along the way.
In Geoffrey’s current role, he gets to work internally doing training and on projects as a sort of “process evangelist.” He brings a lot to the table so tune in to learn all about his community, flow, and data migration.
Show Highlights:
- Geoffrey’s elevator pitch for SFXD.
- How the community got started.
- How Geoffrey balances guiding his community with just letting it be.
- Why he decided to put a Wiki together.
- All about flow naming conventions.
- Recommendations for testing flow.
- What a data migration actually is.
- Best practices for data migration.
- What the cloud information model is.
Links:
Episode Transcript
Geoffrey Bessereau:
I was very lucky. I owe a lot of things to a lot of people that I met around the way. I would’ve never gotten where I am without all of those coincidences.
Josh Birk:
That is Geoffrey Bessereau, a technical architect over at Persistent. I’m Josh Birk, your host for the Salesforce Developer Podcast. And here on the podcast, you’ll hear stories and insights from developers, for developers. Today we sit down and talk with Geoffrey about SFXD, a Discord community he founded, the Wiki in some of the writings around that community and some of the architectural and developer lessons that have been learned along the way. But we start, as we often do with his early days about how his career was taking off.
Geoffrey Bessereau:
So the thing that happened is that when I was implementing, I was just the project manager internally for a very, very small project, right? And I kind of got into Salesforce because I like understanding stuff, and the consultant that implementing it said just, “Okay, well, if those guys will offer you a job at the end of your first term contract, call me up, I can set you up, you know enough that we can probably train you.”
Geoffrey Bessereau:
Well, obviously I didn’t get a job at the company I was at, so I called the guy [crosstalk 00:01:17Nice] and he did in fact recommend me to a small consulting company in Paris, which was called [Luxalar 00:01:21] Consulting. And we did this interview process and one thing that I vividly remember is that they asked me, “Okay, how would you lead a workshop?” And I basically thought it was just like role play so I start presenting myself all over again, trying to just say,” [crosstalk 00:01:36] [inaudible 00:01:36] so embarrassed [inaudible 00:01:38]”.
Josh Birk:
Why?
Geoffrey Bessereau:
Just walk us through the process. It was super funny, they did not expect that at all. But anyway, they hired me and they trusted me enough to just let me shadow on a few projects for just a few weeks and then seeing as I’m a huge Geek, once again, there was a data migration to be done-
Josh Birk:
Okay.
Geoffrey Bessereau:
… So I asked if I could like the time I installed [Judiper 00:01:59], which was the main thing. [crosstalk 00:02:02Right] And I basically had at it so my first exposure to Salesforce, like actual consulting was through the REST API looking at data structures, trying to get data to fit into it. They trained me for a year, threw me on projects, made me get certifications a lock at a time for training. It was an intense work time. There wasn’t all positive stuff, but they did trust in me and allowed me to just grow very, very fast and gave me a lot of urgency to do so.
Josh Birk:
Nice. As somebody who primarily burned sales for at least at the beginning through the DEJX toolkit, I completely appreciate the learning, how sales works work by pounding it against its rest API over and over and over again. Although I think that was the soap API at the time, if I’m being hard.
Geoffrey Bessereau:
It probably was the soap API at the time, the rest API, even when I started, wasn’t always super stable for everything.
Josh Birk:
Right.
Geoffrey Bessereau:
I mean, it was 2014. Right? So you could get a lot of funky errors with a lot of really weird stuff.
Josh Birk:
Yeah, no, that was the transition mode. I think that was when Salesforce was like, “We’re going to be an API first company. Everybody has to start getting on the rest API,” but not all things were created equal nor were they created at the same time at that point.
Geoffrey Bessereau:
Very much not so. I mean, it was, I still remember vividly when process builder came out and I was super excited and I was just like, “Okay, we’re going to migrate all of the workforce to process builder.” And I did it and it was super slow and it kept bugging. And I was like, “Okay, I’m not touching process builder for another year.”
Josh Birk:
All right. So describe your current job to me.
Geoffrey Bessereau:
Well, that is putting new development. So I changed jobs less than a month ago. So I currently provide architecture services for a consulting company called Persistent, which I just joined. And I’m also in charge of creating the technical architecture hub, which is for the moment, at least an internal vocation, trying to just maintain competencies, upscale, guide, let’s say a bit pretty much what Salesforce likes to call evangelists, let’s say, but more on the process side of things and just like internal training. So kind of both project and internal mode.
Josh Birk:
Got it, got it. Well, today we’re going to talk a little bit about in general, some of the best practices you’ve championed and things like that, but kind of answer, as I was researching it, the fact that all of the stuff is centered around the SFXD Wiki. It feels like we should level set there. Give me the elevator pitch. What exactly is SFXD?
Geoffrey Bessereau:
I need, probably need to stop saying ‘err’ all the time SFXD, as I told you the last time-
Josh Birk:
That was a gut reaction, I will admit.
Geoffrey Bessereau:
SFXD as I told you, last time is pretty much a very beautiful mistake, but one that I’m very happy that I did. SFXD was me being bored in November 2016, deciding there should be a Salesforce Discord creating one and basically inviting a Jukebox bot at the time called AFEX and listening to jazz music on the voice Chan, just waiting for people to join and posting the link on Reddit. That’s how it started.
Geoffrey Bessereau:
The very first post was a coworker joining saying, “What is this?” And I was like, “It’s a Salesforce community.” But you’re the only one I was like, “Yes.” And then she left. So, that was the start of SFXD. Now it’s a 7,000 member community centered exclusively around Salesforce and our tagline is we’re a community first Salesforce discussion group-
Josh Birk:
Okay.
Geoffrey Bessereau:
… Which means that we completely avoid any sort of advertising. We completely removed any way for us to actually accept donations or anything, actually for sponsorship. It has no legal entity. It’s very much owned by its members, and we try to keep it very dynamic and very centered on who we actually are, which are all of the members. It is a community of people to speak about Salesforce. Sometimes gets help sometimes vents and sometimes just post beams.
Josh Birk:
Okay. That afternoon you were bored? Was there any moment where you’re, we just need a Discord, actually first of all, why Discord? Why did you go down that route?
Geoffrey Bessereau:
I mean, Discord is pretty awesome. No really, I mean, even in 2016 it was great. And it’s only gotten better. I mean, I’m not saying there’s no faults, but it’s pretty robust. Originally, I actually just wanted to chat space for it. I saw there’s an ISC for Salesforce, which already existed, which has tons of ultra competent people on there, but just like IRC is always a bit complex to get into. I objectively wanted it to be something where random people can just drop in, talk and leave, at the drop of the hat. And that wasn’t going to happen anymore. Let’s say with IRC, it’s quite of old tech and I looked into Slack, but Slack didn’t at the time, public invitations, Discord allowed for all of that, so there was text chat, voice, chat roles, moderation tools, and public invitations. And that was pretty much it.
Josh Birk:
Got it. Got it. Did you have any prior experience to try to do any community building before that?
Geoffrey Bessereau:
Yeah, I did. They were… I was younger. It didn’t always go very well. Let’s say like that. I started by hosting a community about anime at the time when I was something like, I think it’s like 13 or 14. I don’t remember exactly. It devolved into the usual memes inside jokes eleaticism and then inevitable downfall where, when there was not abuse. I learned from that, that another community a few years later around just like it was like a Manga that was online. The same thing happened, but a bit like, let’s say slower. So there was no gigantic moment where it fell into itself, but it just didn’t take off that much.
Geoffrey Bessereau:
And I mean, I realized that communities pretty much have to be, guided and steered a bit, but also being hands off and just enforcing rules and moderating in a way that is transparent and very, let’s say public, is the only way to get the thing going, which is what we’re doing for SFXD. And we’ve gotten positive response on moderation. So I’m quite happy about that. I’m actually quite more than happy.
Josh Birk:
Nice, nice, nice. I mean, that’s, it’s kind of a big deal, right? You’re, making sure that you’re limiting toxicity. You’re kind of guiding the community so to speak, but you’re also letting the community be the community. Is that a decent paraphrase?
Geoffrey Bessereau:
Yeah, it is. And it’s a straight line to walk, let’s say, or it’s a thin line to walk. I mean, my agamatisms aren’t always on point, but [crosstalk 00:08:46 [inaudible 00:08:45]] we’ve managed to get it successfully. So [crosstalk 00:08:48Right] right now, I’m, I’m really happy about all the people that are on our SFXD honestly. I mean, it still blows my mind that we have so many people that just come in, share knowledge and help each other in a very friendly way without being always very reverent regarding the platform. I mean, there’s also very few spaces where you can see as much constructive criticism; it’s going on like that, but-
Josh Birk:
That’s fair? That is fair. Now in LinkedIn, you noted that you collaborated as a community to present a session at Dreamforce 18. What was that like?
Geoffrey Bessereau:
So I’m going to say another beautiful mistake. If a very funny one-
Josh Birk:
I like that.
Geoffrey Bessereau:
… That was the call for speakers that fell onto the end of that. And I just posted onto the announcement channel, Hey, if people wanted to do it and a few members said, “We should do a session.” I was like, “Okay, why not?” So we pulled together, asked for a few people, created a secret channel for it, so we could actually just prepare what we wanted. And we constructed an entire demonstration around login flows and onboard and because login flows were very new, flows were very new and we wanted to showcase you can actually use that to onboard new users to your Salesforce org without actually having to do a thing. So you basically just set it up and have it guided. So kind of a walk me light, light, let’s say, which was pretty at the time.
Geoffrey Bessereau:
We spent few months, one month or something building the Demo, making sure everything was fine and we submitted it and we actually got accepted, which led to the realization that none of us actually lived anywhere close, near Dreamforce. I was in France. Other guys were spread around the US. We had just like one guy in Japan, it was just like, well, so what do we do? So we basically posted another announcement, just like, okay, we need some random dude to just like go to Dreamforce for us and present a session. If you feel comfortable speaking in front of a small arena, just head us up and just like we’ll walk you through it.
Geoffrey Bessereau:
I remember he actually accepted, came in, learned everything that was to learn about the presentation, did the mocks with, well, the Salesforce staff, got accepted again and then went to Dreamforce. We actually still have the YouTube video just saved somewhere. And you can see Christoff, Mealforce from his actual name. That’s the only way I knew him. He was Mealforce to me, speaking for 25 minutes and presenting a project that was delivered by 20 random people that don’t know each other on the internet in front of a Dreamforce audience. And that is probably the most proud moment of SFXD for me still. I know it’s been three years, [crosstalk 00:11:29] but it’s hard to forget it.
Josh Birk:
My gosh. Is there at least a slide in the presentation? That’s like, “Hi, I’m Mealforce, I’m the embodiment of 20 other people who actually put this together.”
Geoffrey Bessereau:
He didn’t say hi, I’m Mealforce but there was a slide I’d like to say thanks to, and on this slide, it’s just like, so it’s like rough copter windeo* and just Mekko.
Josh Birk:
Wow. Wow. Okay. Well, okay. So, I feel like that’s really into the spirit of things. So rolling into that, when did the idea of trying to put a Wiki together come about?
Geoffrey Bessereau:
Here’s with the ‘err’ again. Well, the Wiki itself, I don’t really know. I think I, the website for SFXD was me giving it as a birthday present for SFXD itself, in 2017, I think for its first birthday, [crosstalk 00:12:26Really overdue] It was this like raw HTML code, hosted on GitHub with my very rapidly aging HTML skills. It’s still online SFXD dot GitHub dot IO. It looks as horrible as you would expect cause it hasn’t been updated. And we started putting together a Wiki in HTML form for stuff that we used to do quite a lot.
Geoffrey Bessereau:
So there were a few rants about how to deploy, how to set up a project, how to do data migrations. We used to call them rants because I spent literally 30 minutes just like typing gigantic movements of text and Discords, flooding the chat with this. This is how you should do stuff and stop doing it wrong. And there were quite a few insults in there and basically just like saying, stop doing this wrong. If you’re doing a data migration and you’re exporting data and you’re not exporting it in UTF fake mode using the export tool, we’re not all in the US, there are die hard critics. Use UTF8 and stop wasting my time.
Geoffrey Bessereau:
Anyway, we did the Wiki with this and at some point it grew too big. So I just had to host it-
Josh Birk:
Okay.
Geoffrey Bessereau:
… And well we migrated to Bookstacks. So it became what it is today.
Josh Birk:
Got it. I mean, so that’s some interesting insight because it’s like a… I feel like a Wiki is sort of a kind of chaotic way to try to put together something as structured as best practices, which is a very… At some point almost a very black and white kind of thing. How easy is this to maintain when you have an entire community behind you with a different voices and different opinions?
Geoffrey Bessereau:
Ironically enough, it’s pretty easy. Most people like speaking, but they don’t like formalizing a lot, which means that most of the Wiki content is my own. There’s a few other people that have actual access to it-
Josh Birk:
Okay.
Geoffrey Bessereau:
… And contribute as much as they want to.
Josh Birk:
Okay.
Geoffrey Bessereau:
Any member can log in, create articles as much as they want and edit it afterwards. But there’s just not that many people that like spending hours formalizing documents to throw it on an internet website for no compensation whatsoever. So there’s just not that much Wiki content being published all the time.
Josh Birk:
Okay.
Geoffrey Bessereau:
But what does happen quite a bit though? Is that every six months I have to plan myself a day or two, apologies to reread the entire Wiki because the problem with the practices is they fall out of date. And if the articles aren’t maintained, they’re absolutely functionally useless. So every six months I read the entire thing and just make sure it’s set up to date. If it’s not up to date, I remove the article.
Josh Birk:
Nice. Interesting. Interesting. Okay. Jumping into more specific example, you might have kind of answered that. Something like flow naming conventions feels like something that other people would have opinions on, but is the article like here’s how to name all your stuff and flows? That basically just through the mind of Geoffrey?
Geoffrey Bessereau:
That is pretty much just through my mind. And we already have had some common on how to modify them. I’ve implemented quite a few changes over the year because there were some very constructive feedback about, for example, using standard Java, naming for variables, which was easier than just invading a brand new convention. One of the feedback that I get most often that I haven’t implemented yet is removing the codes, which is just there for historic reasons. The numbering, I mean, two years ago, when flows bugged, you just got a random email with, this is the message and this is the flow name and, havatcha and flows included both flows and process builders. So knowing if it was TPB zero one or FL56 was very useful. Now that the debugging tools are just like very good. It’s not that useful anymore.
Geoffrey Bessereau:
So yeah, no, it is just like pretty much through my mind, but I get feedback. I change it afterwards and I try to keep it as let’s say, as public as possible. One thing that’s very important though and then I’m all stop ranting on I’m sorry, is that these are by no way, these are by no way restrictive at all. This is a way to see what I think are faults in the platform regarding identification and structure.
Geoffrey Bessereau:
In a perfect world, I wouldn’t even have to use any convention. You would just put whatever in it or it would auto name itself, which is impossible, right? I mean, it’s, I would be pure AI [crosstalk 00:16:30Right] and you wouldn’t actually care, but in the meanwhile you need to see what is useful and what is not useful and what I want to use it for, which is why it… The convention spreads it, for example, is it record triggered? Is it scheduled flow? Is it just a flow that I use as a service to other flows? So it’s pretty much just like a service that it calls from various things. And the reason for this is just to identify multiple ways of using the technology. If you read the conventions and you decide those are up to, they’re not for me, they’re too complex or just like, I have another use case. I’m perfectly fine with that. As long as people use any sort of convention, honestly, it’s just a way to see these are the criteria that we’ve identified as being problematic or requiring thought, and that’s pretty much it.
Josh Birk:
Got it. So the end result that you’re kind of concerned about is not necessarily like you follow this naming convention specifically, but at the very least follow my thought process and realize you should think about how these naming conventions are being put out so that your end result is something that’s actually helpful too.
Geoffrey Bessereau:
Exactly. Which is exactly how I put them out on Reddit, for example. I exclusively do not advocate following exactly my conventions. Those are mine.
Josh Birk:
Got it.
Geoffrey Bessereau:
But conventions in general are useful.
Josh Birk:
Now in general, as an architect, are there other best practices for flow that you would recommend?
Geoffrey Bessereau:
Quite a few, but-
Josh Birk:
Has that a whole other episode?
Geoffrey Bessereau:
… Yeah, I pretty much think so. Honestly like flow speci… I have very strong feelings about flow in both positive and cautionary ways, which I’ve been quite public about in various avenues. I think flow is probably the future of the platform in a lot of ways. And I love all of the energy that has been invested in making it reusable, more user friendly, more accessible, but the fact that it’s getting so powerful is also making it be pretty much just code with the GUI. And the fact that we’re… I think lying to admins, telling them, “You can use this, you can actually do whatever you want with it,” Is making orgs have a bit of spaghetti code, which is kind of a weird place to be in because, well, it’s not exactly code. It’s not exactly declarative either. It’s somewhat in between.
Josh Birk:
Right.
Geoffrey Bessereau:
So there’s a very fine line to cross, I think regarding, okay, it needs to stay purely declarative, but you also need to make it so that the guardrails over there so that people don’t do stuff that would actively harm not only user experience, but data, I mean, it is perfectly possible to do flows that won’t completely override your… The data in your accountable. For example, you probably don’t want that. So,
Josh Birk:
Well, let me, let me repeat back to you something I’ve heard on the pod several times and feel free to just basically rant on after this. But what I’ve heard from several people, is that they kind of push back on the whole… When you’re using flow, it’s a no code, totally builder tool. They’re like, it’s kind of visual code. And it’s helpful to think about it in terms of a functional coding language when you’re actually trying to put it together.
Geoffrey Bessereau:
Oh, I fully agree. For me, flow is definitely code. There’s almost no way around it, which is why I’m saying we are lying to admins saying that it’s fully no code. It’s not, it is code. It’s good with the GUI.
Josh Birk:
What are some of your recommendations around testing flow?
Geoffrey Bessereau:
What I would love to see would be specific testing flows, my test classes where you can actually say, this is what the user is going to do, because you can actually do that quite easily in flow, right? Not only save data, but capture it via streets, which means you can actually use flow as a selenium mockup type where you basically say, “Hey, put all of that information in there and then do these data operations. And here’s the result that I expect.” And if you could do this, not only to validate your own flows, but also to validate apex classes, I would be so happy. Imagine, just imagine for two seconds, an actual full-fledged admin, who’s been with the platform for a few years and has learned flow because it’s the new best practice and it is put into their hands and they go to their business owners and they ask them just like, okay, these are the things you want to do.
Geoffrey Bessereau:
So just tell me how it’s supposed to look like in the end. And they just decide, okay, I’m going to do simple screen flows, really simple, almost no logic that says this, “Well, if I do this and then I call this flow and then just like this, I expect this to happen.” And you get your entire testing structure just in flow, maintained by admins, easily editable with just like business owner logic directly behind it. Calling app access is calling flows, calling whatever, and just allowing you to see very easily using the debug tools they have already put in place where exactly it goes wrong. You cannot tell me you are not excited about that concept. That’s for me would be godly.
Josh Birk:
Absolutely. Absolutely. Okay, so let’s talk about a few other things that are in the Wiki. For instance, there is a data migration guide in there which looks brilliant. Can you walk through and you kind of mentioned it a little bit earlier. Can you walk me through what’s in that on a high level?
Geoffrey Bessereau:
Let me just load it for two seconds. Shouldn’t take too long.
Josh Birk:
I like it.
Geoffrey Bessereau:
I mean, I wrote this quite a few years ago by now that data immigration guide. So, I mean, I’m actually [crosstalk 00:21:41To be honest] going to publish a new version.
Josh Birk:
Okay. Okay. It is very detailed, which I appreciate.
Geoffrey Bessereau:
That’s why we called them rants. That was a lot more profanity in there originally. So yeah, no, I remember this. So the data immigration best practices. So you, originally, this was only one big text that was posted in Discord as raw markdown-
Josh Birk:
Really.
Geoffrey Bessereau:
… So the fact that it’s actually spread into three different articles is as I said-
Josh Birk:
Okay, so now I got to ask, was there a data migration project that wounded you, that was like, this is why you wrote this thing.
Geoffrey Bessereau:
No, it was the multiple help requests from people on SFXD and there was one in particular where [crosstalk 00:22:26Really] basically they damned their org for at least a couple of weeks while I, they had to pay the 10K fee to actually restore the data. And I was, “Okay, you know what? Just like people inside consulting companies mostly don’t do that. That immigration is well, sometimes people and clients don’t do them well, sometimes people at Salesforce don’t do them well, sometimes.” At some point in angered me, I was like, “Okay, you know what? I’m going to stop everything insertive here. I’m going to write you a big grant and you’re going to follow this.”
Josh Birk:
Wow. I don’t even know if I’ve got to follow to that. I don’t even know if I want to know.
Geoffrey Bessereau:
You probably do not. No, no, no. It was, I mean, there’s not one single thing, right?
Josh Birk:
Right.
Geoffrey Bessereau:
… It’s not a company, [crosstalk 00:23:13Right.] It’s not a person. It’s not an entity. [crosstalk 00:23:15Right.] You got to realize this is in my opinion, systemic failure to actually understand what a data migration is. And a data migration is at its core, a destructive operation. That is not something people tell you. That’s not something people actually mostly stay in mind because they think, oh, that are migration. It’s a migration. [crosstalk 00:23:33Right.] I take it, I put it there. And then that’s pretty much it. They don’t think about the fact that you’re overriding tables, restructuring data, that your rejects are actually also data destructions on some level. Because you know, it’s pure loss and you actually have to think about, okay, at every single step of the process, if I do something wrong, what is the worst that can happen?
Geoffrey Bessereau:
And the worst that can happen, thankfully with software is not that you drop the table because you have to do a delete for that. Right? But you can’t however, do something that is much worse. You can actually overwrite the data. And if you overwrite the data with blanks, with moles, with anything else or help that imagine that you load the data with the wrong encoding and all of a sudden your accents are all completely fetched up. Well, imagine that. And you don’t have a backup. [crosstalk 00:24:15Right.] It is that it’s called a purely destructive operation-
Josh Birk:
Nice.
Geoffrey Bessereau:
… Which led to the data migrations thing. So I spread it after a while. I actually split it into checklist before loading and during loading, the checklist is basically just here so people can say, “Okay, I’m going to print this out. I’m actually going to put it on my computer. And the next time I do a migration, I’m going to follow this because once again, I do not want to destroy my entire org.” The before loading at its highest level is mostly just be smart, have a backup process, your data and make sure it actually fits in what you want to do. That’s at it its highest level-
Josh Birk:
Got it.
Geoffrey Bessereau:
… That’s pretty much it. It’s just [crosstalk 00:24:53Okay.] ensuring you have a rollback setup and ensuring that you don’t go head first into something that you just don’t know what’s going to be on the other side. When you do the data migration and production, you want to be certain of the result. It’s not going to, wait and see kind of thing. No, you already know [crosstalk 00:25:09Got it]. Then you actually implement. [crosstalk 00:25:11Right].
Geoffrey Bessereau:
And finally there’s the loading part. And the loading part is literally do the things you have already done. Make sure you’ve already followed the checklist and then click the button. That’s pretty much it, because normally your entire job is done before.
Josh Birk:
Got it.
Geoffrey Bessereau:
Your job is done before the loading.
Josh Birk:
Right. So think like a developer and be like, before I load this into production, everything’s going to work. Okay. Like pressing the green button to deploy the production shouldn’t be like, “Well, this should be fine.”
Geoffrey Bessereau:
I wouldn’t say think like a developer. I would say, think like a paranoiac. Think about everything that can actually possibly blow up, go wrong or actually mess up your organ plan for it. [crosstalk 00:25:49I like it] If the worst that can happen is something that you’ve already planned accounted for and have a role back now for you’re fine [crosstalk 00:25:54You’re fine] . I’ve actually overwritten data in my time. Right? I’ve done wrong operations. I am not like clean as a whistle [crosstalk 00:25:59Right]. I’ve got like eight years of experience I’ve done some bad things, [crosstalk 00:26:03Right] But I have backups. I’ve had backups.
Josh Birk:
Nice. Nice. Okay. One of the other things you have on the Wiki is release notes highlights and I’ve done release notes highlights and they can be really time consuming. Now, does this follow the same path of this is sort of a ran from Geoffrey’s brain and everybody sort of follows suite with it or is it more of a group effort?
Geoffrey Bessereau:
No, that one’s pretty much just all me [crosstalk 00:26:27Okay]. I rely heavily on a couple of people for specific parts of the platform that I don’t know, James, who you’ve interviewed generally helps me with everything related to development. He has a very good eye for that and [crosstalk 00:26:37Nice], well, it’s just much easier when I get his input. I have [Super Grape 00:26:43] who does everything that is related to Einstein analytics in Tableau [crosstalk 00:26:48Okay], because he has a lot of experience with that. And I generally leverage [Merkel 00:26:52] and [Mac Mouse 00:26:52] for the CP2* parts as well as [Luca Savic 00:26:56] for the field service lighting parts.
Josh Birk:
Got it. Nice. Very, very nice. Now, one thing you’ve told me about, which I don’t think it might be referenced in the Wiki, but it’s something you kind of told me about separately that I am delighted to learn exists is the cloud information model. What exactly is that?
Geoffrey Bessereau:
So the cloud information model has nothing to do with this SFXD but it’s probably one of my favorite things on the internet right now, combined with the Salesforce organization governance model, that’s pushed by Salesforce architects, which is another thing. And the cloud information model is, how did I manage to define it last time when we spoke? I don’t remember. It is basically a standard for data structures between giant corporations based on specific use cases [crosstalk 00:27:46Right] or to rephrase it on a pure example on basis. It’s if you want to know how you’re supposed to structure your data for invoicing, because you want to actually build something, you look at whatever the cloud information model has said, “Hey, we’re doing it this way because this is a model that’s being used by sales.” I mean, not used by Salesforce, but Salesforce is on the go say, if I remember as well and a few others, and they’re literally just pulling together this gigantic data structure.
Geoffrey Bessereau:
Now this is not something that you can use as is like the data structures that are presented in the cloud information model are gigantic. We’re speaking ERP class enterprise level of table development, but it gives you an idea of how they actually thought about the structures. And I don’t think there is anything that I like more in the current age, let’s say of standardization than standardization across different companies. It is… You do not want to rebuild data structures and data tables across an ERP to a CRM or two. And then I actually have to just cross map everything.
Geoffrey Bessereau:
It doesn’t matter. The software does different things. The data structure shouldn’t be that hard to modify or to fit together. And that’s what it’s bringing. It’s bringing like a factor of standardization across different, huge solutions and an idea of how to put in place different big models, which I just love, I I’m in love with it. It hasn’t been updated in almost nine months for the moment. So I’m hoping it stays alive, but [crosstalk 00:29:12Right]. I am very much in love with the concept.
Josh Birk:
And it looks like it’s got like JSON and cicle. There’s different ways that you can kind of try to implement this and use it within your own devices.
Geoffrey Bessereau:
Very much so. And they’re working on like a ton of stuff. I mean like the data models go from the actual setup of software all the way down to market ready solutions for how you actually want to do prior in a privacy content, how you handle sales orders, how you handle cases and assets, this sort of thing. Which may seem a bit weird coming from Salesforce because, you know, cases are standard objects. You don’t want to touch them, but there are a lot of other stuff and that are around cases around how you managed not only entitlements, not only milestones, but also just okay, who are the different agents that are working on it? What’s my SLA. What is the service contract? What is all of that? And Salesforce standard objects do go a large way towards that. But sometimes you have to go custom. And when you have to go custom asking yourself, how does the industry do this is a great question.
Josh Birk:
And that’s our show. Now, before we go, I did ask out Geoffrey’s favorite non technical hobby,
Geoffrey Bessereau:
I’m going to go with a piano-
Josh Birk:
Nice.
Geoffrey Bessereau:
… I don’t spend enough time on it. And I’m still very mediocre after multiple years of actually trying to be any sort of good at it, but it makes me happy and it makes other people happy enough that they can listen to me for at least two minutes without completely leaving the room. And I consider that a waste.
Josh Birk:
I want to thank Geoffrey for the great conversation and information and as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer dot salesforce.com/podcast, where you can hear all the episodes, see the show notes and the links there. Favorite podcast service. Thanks again, everybody. I’ll talk to you next week.