Andrew Fawcett, who joins to talk about Apex v67 User Mode System Mode, is a Independent Salesforce Consultant, Former CPO on Heroku (Salesforce) and CTO on FinancialForce.
Main Points
- Andrew’s background & return
- Why Apex User Mode matters now
- Principle of Least Privilege
- The breaking change: API 67 default flip
- The three paths (A / B / C)
- Permission sets are the prerequisite
- with sharing vs user mode — the subtle gotcha
- The missing piece: granular elevation
- Why Salesforce is doing this now: AI & Agentforce
Links
Video
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:14] Hello, everyone. This is Xi Xiao. This is the new episode of Salesforce Way podcast. After so long time, today I have a returning guest. His name is Andrew Fawcett. Hello, Andrew. Hello, thank you for having me back after seven years. I think the last time here on the podcast was two thousand nineteen. Wow, time flies! Time flies. So, what you have been doing? If you can shortly brief us up for these seven, eight years. Seven years. Well, I think probably around that time I was at Salesforce. I think as product leader. So in that time, I've been working on Salesforce platform, but latterly and largely, mostly on Heroku as their chief product officer, ultimately, and enjoying the ways in which we can bring the Heroku technology into the Salesforce ecosystem, as well as also. Expanding Heroku within the broader pass market, so that was an enjoyable time at Salesforce. Obviously, we're we're probably all aware now what the the kind of conclusion has led to with Heroku is pretty sad, I must say, from a personal point of view. But nonetheless, the the team there and the product that we created and drove, I'll never forget, and the experiences that we got and learnings from that have led led us to where we got to today. So. You know, much appreciation for Heroku and very honoured to be part of the Heroku history. But Salesforce has has
[01:44] been a big chapter in my career. But another chapter has opened up that's allowed me to explore a more work life balance, and that's being a consultant, and has led me back to being more hands on with customers and clients. Where I'm either doing advisory work on products or strategy or technical strategy, building proof of concepts, doing research. Or even creating content for some clients, so it's a really good spectrum and a mix for me, and brings me back to some of my original days, really hacking around the platform and the community. And the Roku time really allows me to explore much broader spectrum as well around just not just the Roku platform, but how you integrate with it and bring other platforms. Integration into it, and of course, unescapably AI has come into the mix with the last few years, and not only Heroku's AI offering, but obviously Agentforce as well. So, spending a lot of time working in AI in and around that, also with ISVs as well. So, really enjoying the consulting world right now, and it's it's really fit for where I want to be in my life at this stage. So. And happy to be taking the time that I can. You know, I think there's a reason, probably, why I've not been back for seven years, and now I'm back now in this current new chapter of my life. So happy to be here. And you know, I think when you and I chatted about this podcast, there was a lot of different ideas, but. Some of those we might get back to, but recently, of course, we've been talking about
[03:14] Apex User Mode and that blog. And really, I jumped at really writing that blog because it's something that's been something missing from the platform from the very inception. So I think that's really where we were going to dig into in this session. I'm delighted to to share a bit more of my thoughts beyond the blog and what folks should be thinking about. Yeah, but if we. One back, like go one step back. How did how did it really fall into your radar with this? It's it's just the summer release, right? Like the winter yeah, I mean it's really um obviously I do I've re re um point re anointed myself with kind of just the the luxury of just sitting down and pouring over use over the release notes all the time. I love that, and we get excited about that. So obviously, I saw that feature. But I've been tracking for a while. Both when I was in Salesforce for a time, I was responsible for the Apex runtime as well. How the Apex team have been developing. Easier ways than the original CRUD and FLS checking methods. You know, I was aghast at really the way that that had to be done. Especially as an ISV, you literally had to litter your code with, you know, describe checks to see if you could write or update a record or read or update a record or have access to a field. You know, that was very noisy in your codebase. And so, you know, we. We explored frameworks to help us do some of
[04:44] that, but it just was very painful. So eventually, Apex added. Clauses to the Sockle queries and also different parameters to the database DML operations to run as user mode, and that that's been with us what I think maybe maybe three or four years now, but it really wasn't a requirement. And this time, it really is a requirement to understand, and it's a huge shift for the Apex runtime because many people have just assumed it can access everything, and that's just the way it is, but. When you look at the reality of coding, in general, in the industry, the principle of least privilege is a really important one to learn because. Especially in the days that we live in, the most significant amount of crime is typically cybercrime in hacking and getting access to data. And you know, sometimes the nature of some of those hacks are are so deep that it doesn't matter what you put in your code; they've got access. But sometimes it is important to make sure that if they've got access to run certain elements of the code, that code can't do more than it was intended to do. And so. Principle of principle of least privilege means that that code can only access the data and the fields that it needs to do what it has the purpose what it needs to do and no more no less. So that if anybody's running as that. The user that runs that code, then they can't do anything else necessarily
[06:15] to access data, and that's really one of the key principles. And that's been around since like Unix days. It's for a very long time. And you know, sometimes when I remember moving from Windows to Mac, I was banging my head against all these CLI commands that just weren't working. I had to understand what sudo was and things like that. And eventually, I realised that's a good thing because you know, even running on my own computer, it's safeguarding what I can do. And saying no is a minimum. You're going to have this. You have to elevate your permissions using sudo to do that, and that creates a really safe mental model because it makes you think about security, and it's painful if you haven't been. And it was when I moved from. Windows to Mac, but now I am like, yeah, I get it. Thank you for doing that. When my scripts fail because I haven't got the admin privileges on my machine, I am like, great, thank you. Because if there is ever a script that I don't know is running, gets that I want that to fail as well. So, you know, what caught me eye with this is it's it's probably the biggest shift. We talk about lots of things in Apex that's happened over the years, big new features that's been added to it. But I actually would say that this is is probably the biggest since its inception because it completely flips around that security model. Once you run Apex at API sixty seven, if you run a query. We're trying to attempt some DML. It's going to fail if the user doesn't have the right permissions. Yeah, so I will attach your blog
[07:46] post uh to our show notes. So for the people who want to read uh everything, in details, but here you already mentioned the least privilege uh principle, right? That's what actually drive this change in Salesforce for the security control in Apex. So, in my naive understanding, is that in the past, the Apex code by default runs in the system mode, which basically means it has access to the all the objects, all the fields, and even. I think there is this with sharing without sharing. That's that's the record level. Yeah, we should talk about that in a moment. I think because that is still different. That's a subtle differences. But what I'm trying to to tell here is that in the past the door was like a bit wide open, right? Every the code runs for the developers is that we tend to. Follow the happy path. The code runs. There's no error. Nothing's blocked. Then we're happy. We ship the code, but then maybe we don't really need the door to be that wide open, right? We should keep it a bit narrow. We don't need. The Apex code to access all this object, all these fields, even though it still worked in the past. And it was the developer's role to
[09:16] to set whether it's like the system mode or the user mode, as you said. But in the past, we didn't even have this user mode term. It's called with yeah. The nearest you had with user mode was really just checking the permissions deliberately in your code, which was largely quite a chore to do that. Right. You have to check every single field. Yeah. I mean, right. It presented a huge amount of overhead and. And noise in the code to to do that. So we really didn't have user mode until it was officially introduced a few years back now. But it had to be still an opt-in thing. You had to change your code to do it. Yeah, because I remember a lot of the customers I worked in. Uh, when I checked the Apex code, a lot of SOQL queries they don't have any this with security enforced those those terms. Uh, I don't know, it's the annotations. I think it's because at the very beginning Salesforce the SOQL queries doesn't have those uh keywords. And then that certain point, then it's introduced. Yeah, for SOQL, I mean, this is this also represents a point where there's been a kind of evolving story of how it how it's worked within Apex for SOQL. Because with security enforced is disappearing as part of this change, and it's only with user mode or with with user or with system mode that you have. It's very clear now the two, and those those mirror what you do with DML as well. So that's a bit of a legacy. Keyword to use,
[10:46] but you still have the user mode and system mode in SOQL and user mode and system mode parameters for your DMLs. Okay, yes, you have to apply them, and if you if you're not applying them, I think that's the You know the path C that I talk about in the blog. You're just not yet ready to switch this on because what will happen is as soon as you move to API 67, you'll start getting exceptions from your Apex code because likely the profile or the user. The permission set, rather, or the profile that the code has historically been running under doesn't have necessarily all the permissions. So you might have given, you know, I've written some Apex code to go and generate quotes from an opportunity as the example I always pull to a more businessy, understandable operation. You might have given users access to those objects and some custom objects around that service. But you might not have given them everything, and you might not have never noticed because the Apex runs as system mode and it just merrily accesses everything. Yep. So then this is that point I was talking about early. You might say, "Oh well, I'll just patch up the permission set or the profile to add the missing fields and objects." And that's where I say, "No, don't don't resist that. You need to step back and say what." Fields and objects does the user need versus what the code needs? Because if it's fields and objects the code needs, then that's when you should be explicitly using system mode. Um
[12:16] and you know with API sixty seven you don't need to explicitly say user mode because it's there by default but you will need to explicitly say system mode and that's the proper thing to do. Um, if really this field, just let me repeat if I understand correctly. So before version sixty seven, if you Implicitly, don't give any keywords in the SOQL or DML, then that's by default the system mode. But after version sixty-seven, it flipped the coin. By default, is the user mode, mode which is more tied tied to the user's permissions. Yeah, and then a lot of code could fail, right? If I never really add those keywords in my code, and I have a millions of Apex classes, then Yeah, particularly your tests might fail as well. Your Apex tests, right? Because unless, even if you're being using run as in your Apex tests, the user that you're running as might also not have the right permissions. So your tests, your Apex test might fail. Your user interactions might fail. And those test of failure actually are good because they catch the real scenarios. Yeah, exactly. And your end user failures, while not ideal, are good as well because they show they're bringing to light. You know, is this permission missing? So really, you know, if you have been using user mode and system mode since they've come out
[13:47] over the last few years, then you're in a kind of good position, which I call Path A in the blog, because you've really started to understand what code paths need user mode and which code paths need system mode, and you've annotated accordingly with those features, and. Switching on this default user mode means that where you've annotated runners user mode is a bit superfluous now because it already is running as user mode, so you don't need that. And you can go ahead and take those out, but you could leave them in. That's they're harmless. So if you're in path A where you've you've deliberately been cognitively using system mode and user mode in your SOQL and DML, then that's great. What you might find is like perhaps some of your tests or other or your permission sets maybe aren't fully sort of designed in the right way, and I talk a bit about that in the blog. No, but largely you'll have probably figured out the correct permission sets and profiles because you understand the difference between system and user mode. But if you're in kind of what I call Path B, where you've kind of got some Awareness of testing permissions. You'll have started putting the right profiles and permission sets together, but if it's not throughout your code base, you're still going to get some failures. But mentally, your development team and yourself have been aware that you have to have permission sets. Largely, I recommend permission sets over profiles. You have to have them in place
[15:17] to be a digital representation of what your security model is. You know that's really probably the most important thing here is having awareness of what a permission set is and how to design them properly for your business scenario. And so, path B is a good place if you've already started using user mode because you kind of got your head around it. And path C. Is really, you haven't really, as you explained, you've just been used to running in system mode. You've got none of these user mode clauses or system mode clauses in your code whatsoever, and that's where you're really going to have to sit down and make sure everybody understands the difference between user mode and system mode and design those permission sets. But you also, in your blog, I remember you mentioned that the permission set is a prerequisite for this task. Is it really so? Yeah, permission set groups are also handy, and one of the things that I think I'm going to do as a follow up blog is kind of share some views on how to design permission sets because. Depending on the size of your what you are building, you might have one permission set. Maybe it's just a very discreet feature, and you have one permission set, and you assign the users that permissions to those objects and fields and whatever you to do that job. But if you are building maybe multiple features or an entire application. Then you might have features that are applicable to different personas or roles within your organization. You might have somebody that's an admin of that app, or a power user of that app, or or read-only user of that app.
[16:47] So you can arrange your permission sets to represent those roles, but also group them together for power users using permission set groups. So in the past, without a permission set group, you might have had to have lots of permission sets that really overlapped over each other and duplicated permissions. Now you can kind of create. Smaller, more fine-grain permission sets, and group them in different ways to represent the different personas of your application. So there's a whole science behind designing the permission sets that I kind of want to elaborate a bit more in a future blog. Okay. So you're right, that is an important area. If you've not, if you're listening to this, wondering what a permission set is. Then don't dive into this until you fully understand permission sets and permission groups. Profiles might be something your organization uses a lot. Certainly, when I connected with the product managers for Mission Set, so I was aware that they were trying to get more adoption, and it's you know orgs. Some of the orgs we deal with are very old, and profiles are very prevalent. So profiles are an option, but they're just not as That you can't really decompose your application and your features in a way that permission sets allow you to do. So, but the same what I'm saying here would apply to profiles, but obviously they're just less flexible. So I would try and use this as an opportunity to maybe drain some permissions from your profile and and push those over into permission sets. Yeah. You know when you mention the path A
[18:17] B C and using uh profile versus permission set, I put myself into those buckets like where my customers are in. I think I'm kind of like in this uh this bad situation at the moment, and also most of time I'm not working as the I S V vendors. I'm working with like one single org, the customer with the customizations. And I do see a lot of them still using profile and large profile like assistant admin profile, whatever profiles, and and then they are they are really in the past. See at the moment, because the the security designer are not that clear, especially when the code base is really large. Yes, it is, and and I think you know the design the the because profiles and permission sets are all one big overlay. When you assign to a user, it does give you the opportunity to crawl, walk, run. You know, often we need that kind of approach when we're when we've got large code bases or large orgs. We need to be able to take slices off each time to make incremental progress. So my my general thoughts there would be just make sure if you're migrating a certain amount of code and let's face it, you don't have to move all your code base to API sixty seven. You could also move some of it and do this transition incrementally, then. When you encounter fields that are used
[19:47] by that code that are genuine user fields, and you think they're in profiles, now that you know that list of fields and objects, consider lifting them out of a pro of the profiles and putting them in a permission set, and then you can just immediately assign that permission set back to the same users. And as long as you put what you've extracted from the profile directly into the designated permission set and assign it, then because it's a big overlay, they don't see the difference. So, you know, there is an opportunity to drain profiles. Intelligently, you know, precisely, and move them into permission sets incrementally. Yeah, we take small steps, and each step has a feedback loop. If you did something wrong, you missed a permission, then the user will give you the the feedback, telling you that cannot access. Right. Yeah, and repeat, and going forward. Yeah, I mean the the feedback loop is a good opportunity to talk about Apex tests here as well because Apex tests can run as different users. I think there's even a way to run all your tests as a different user than the than the user that you're running the the operation as. You know, because historically we just click the run test button or we use the CLI and it runs the test as the user that's creating that test job. But now I think you can give a different user now. The reason why I don't particularly like that that
[21:17] option is because it may be that certain tests need a different type or persona of user or different permission set, and it's kind of saying that all of your tests need to run as that user. And that user might have multiple permission sets and one profile that may be too much for what those tests need. So the the preference that I really like, and it's been in Apex for a while, is to be able to run as a certain user. What you need to do in your Apex code, of course, is have a utility class that creates a user, and then that would assign the very specific permission sets and run as that user. And the benefit there is that you could have something in your test setup code that says create me a user with permission sets A, B, and C. Then in another test, you could have create me a user with permission sets C and D. That way, you're really testing your permission sets and just those permission sets against your discrete Apex tests, and you have much more confidence because in reality, if you're just assigning those being A, B, and C permission sets to the users, the test runs those permission sets, then it should work. Right, so we can on the fly create create the test user and also select or handpick whatever permit permission set faces into the test setup. Yeah, you can automate all of that in in Apex, um, in your test setup, and run that. And of course, if you're, I mean, obviously this only applies. Another passion of mine, if you're not using true mock
[22:48] test unit mock testing, because then you're not hitting the database or the DML. But if you are running like unit Apex tests that typically read and write data, then you have to run as a user with the right permission sets. Is the purest way to think about this. There is always degrees of what's possible depending on the complexity of your org to explore here, but. That's the ideal situation. The other thing we've not really spoken about here is sharing, and it is a little bit a little bit confusing. And I noted it in the blog. Here is that we're used to having without and with sharing to control the visibility of the records the code can see or not see, and it turns out that user mode does ignore with and without sharing. It will always. Enforce field and an object access, and it will always only return records that the user can see. Whereas, when you're running in system mode. You have to use without sharing as well. So if you're elevating your Apex code, say you've adopted API 67, and everything, you know, 80% of your codebase is running in user mode, then you can be assured that the Apex runtime is checking your fields, your objects, and your record sharing for you. But if you then have the other twenty percent of your code or whatever that wants to run in the elevated system mode, then
[24:18] you have to run in system mode by tagging it in your queries and on your DML, and you also have to have without sharing in your class. Yeah, just make sure I got your idea correct. Is that? When running the code in the user mode, it will kind of override the class a way or without sharing or default to the way sharing to use the user's record permission. But if it's a system mode, then it will still check the class: is it with sharing or without sharing? It's it's indeed a bit the. It is, yeah. I've screenshotted the bit of the documentation. I'm looking at it now in the blog that says that.
[25:01] So it could be a little bit of a gotcha, yeah. Yeah, but I I can understand where it comes from because again, it's this list privilege principle, right? When you run in the system mode, you keep it still in the list privilege. Right, it it defaults to still to check the class. Hey, if you are with sharing, yes, right. Hey, let's keep it still. The door tight. Don't open it too wide. So yeah, I mean, explicitly mention that. That that that does bring us neatly onto another thing where you know we're not quite done with this story from Salesforce yet because we have a very clear story with user mode. But with system mode, the principle of least privilege does require an elevation model. Method and you might think we've got it with system mode, but that's kind of super super elevated because in some cases, what you really want to say is like I'm doing all this logic for these business objects, and maybe I write to my log objects. You want to elevate just do take the user permissions plus only the log object, but system mode says everything all of a sudden. So for those moments you are running in system mode, you are kind of back to everything being accessible, which is what we're trying to avoid. So for that reason, there is a dev preview feature. Um and I had a good conversation
[26:32] in one of the Slack channels, public Slack channels, with the PMs about it that they're pushing to get this done, where you can. Run in user mode with an attached permission set that will elevate just enough to give you that extra level of security and access to that log object, but won't elevate to the full system mode. So that's the missing piece of the puddle. Is that you haven't got more granular elevation at the moment. You can only elevate to full system mode. What you really want is kind of my apps system mode, which is my app objects, you know, system objects, not just all of the objects. So that's that's I think linked in um in the in some of the comments on my LinkedIn post. Actually, I don't think I linked it in the end. Did I link it at the bottom of the blog? I can ask you later to get the link. Yeah, but but to me it scared me a little bit. I understand it's a good principle. We can have a fine-grained permissions once we elevate it up. But now we have the system mode, and then later we introduce this new feature to fine grain. Then we need to touch, change our code shape again to to downgrade. Then we can send. Be I think you know if you're going to go through if you're particularly in path C here where you haven't really thought about security, the big point I'm making the blog is that actually you have an exercise to do to map out what your personas are that people use of your your code, your application,
[28:02] and also map out what objects and fields are used in what context, user or system mode. If you've got that mapping. And you captured that, or you're maintaining that. Then, when it comes to creating a permission set for your own app system mode, then it's really just making sure that you're adding those system fields and objects to that. And using that feature, I don't know what Salesforce will do when they add this feature. Hopefully, they won't completely remove system mode, because I'm sure there's. Well, I know for a fact there's a lot of utility packages. The LRS, the Rollup Lookup tool, needs to run in practice by its very design needs to have access to a lot of objects. So I don't think they'll remove system mode. So When that arrives, this more granular one, you'll have time to adopt it and keep your homework from this phase to know what your system objects and fields are. And as I say, if you've got your code well structured, you should know what module to go into and what methods and things to go and apply that to.
[29:09] So yeah, don't don't lose sight of the analysis and research that you're doing because it will help when that feature comes along. Arguably, you could create the permission set. The system permission set for yourself now, but it's probably it's just not going to get used until this feature arrives. So it's just kind of added overhead until it arrives. So maybe you can add this thinking and a good solution in your next blog post. Yeah, do we can steal from you? Yeah, yeah. But I mean, it's a good feature, and it kind of. Served as a wake up call for all the customers, right? You need to do the security control, but to me, when I think it through. It's a hell of a lot of work here for those path C customers, especially they need to keep the business running and they may want to add new features on the go. So, I don't know how big of task that it is, and well, as we were talking about earlier, just break it down is my advice. And fortunately, you you don't have to move all of your classes to API sixty seven. It's never been a requirement from Salesforce to do that. I know. When I was working in the ISV world within the package, we would move everything because it just creates corner cases for backwards compatibility in the Apex runtime. If you have some classes running
[30:40] at one version and some at the other, you know, and I have in my past, you know, over like fifteen plus years now, encountered some quirks where I've had a mixed code base on some API versions and some others. But you know that is an option for large code bases, particularly if you've got some reasonable separation of concerns. Like this set of classes is just for this module for this part of the business, and this class is just for that. Then you could think about doing it that way and incrementally adopting. The API sixty seven, but I think you know ultimately the reason Salesforce has done this is that it's also tied with evolving your business around. Other ways in which your Apex code gets invoked, and predominantly agents. You know, we see now that you can attach Apex code into Agentforce, or even call it in other contexts. And so, as your you and your business moves more into adopting those sort of things, then you should really consider this drawing down the budget for adopt for your cost of adopting AI, and therefore the benefits of adopting AI. Because there's an argument to be said that this is kind of AI proofing the security of your code in a way because. You know, not everybody's going to jump at exposing their Apex code to Agentforce, of course. But the ultimate flexibility is that the code you invest in is used in as many places as is it's useful. And why lock it out from? AI,
[32:10] for the sake of not having this right security stance, I think it's really interesting just to see that since the AI wave arrives. Now people pay much more attention to the Unix philosophies, like what the things you mentioned. The list, the privileges. A simple tool should just do one thing and only one thing. And the CLI tools, all these things. I also see Salesforce started to. Introduce the headless three hundred and sixty, and the AI agent is coming to use the platforms. All these things actually really tight link to the security controls. We need clean our technical debt to make sure the platform is in a good shape. Yeah, I mean, I could totally imagine that this this feature has been the flipping around the the security mode in Apex runtime. Has really been considered both publicly and and to some degree, you know, thinking about how it could even be done hard, right? As a hard problem, but it has been solved now. And I've got to imagine that it was for the reason you've just described that in order to promote Salesforce headless, even think about code being reused in an agentic AI experience. You've got to have this, and you know I think this is Salesforce putting its foot down and investing in this feature to secure itself as well as others for that future ahead of us. You know, because the headless side of things is:
[33:41] are you really going to restrict yourself to? Just your objects and your CRUD operations being exposed, or do you want to expose some of your business logic that you've invested in over the last you know ten fifteen years? Because it'd be wasteful if not, but you might not because you haven't got security in, and therefore you kind of spot you're kind of kind of high. You're kind of avoiding that value being. Exposed by just not having the security in place, and and obviously the the the fear of that being a problem is is real. So I think it's about unlocking. The business value you've put in your Apex in a safe way—that's what this investment's going to allow you to do—and like more value of that past investment. In a safe way. Thanks a lot, Andrew. I think we had a good wrap up since we started with a lot of details. Then in the end we concluded. I don't know. Before we leave, do you have anything you want to add still?
[34:46] Um, I think the the the thing that I'd probably wrap up with is think about tools that can help you with this. There are a lot of tools these days that will help you explore your Salesforce environment. Look at the dependencies, which will help you understand that. You know, sometimes in Apex we may. Dynamic dependencies on fields and objects and things that that needs more kind of different techniques. But largely, if you're not using dynamic Apex, then these org exploration tools will help you understand how to build those permission sets, or at least know what fields are being accessed and such like and objects. Salesforce security scanner and PMD rules. I think since I wrote the blog, I've seen some posts saying they have started to get updated. So they might help you, and then frameworks. There's a number of frameworks, including those that I've worked on, and others that are actually wrapping SOQL or DML. You know, I've seen Unit of Work or Fluent. There's the Fluent-based frameworks that are out there. They all will run as user mode by default if you adopt those. Okay. So yes, I think my closing thoughts are. Look towards tools that help you do the analysis and the discovery. Work with your organization on what roles are being used. Roles and personas are often very boring things. Sometimes, in my
[36:16] experience, it's like, well, everybody's using it, but okay, okay. If you have the conversation, it's just one type of user, great. But if there's different types, you will need to think about. The access controls in a different way, so use the tools to scan your org. You have the conversations with the business about the personas, and use the security scanners, and then think about libraries and frameworks that can help you. You know, adopt default practices. I mean, and these things you could do now. You don't have to wait. You know that we we all kind of like to put things off in life. But here's the thing: come the moment where you need a feature in API 67, you know, one of the other new features, or in API 68 or 69. And you haven't done this homework and this this grounding, you'll really regret it. So if if you don't, even if you don't plan on moving straight away, do the work to to use user mode and system mode because you can do that now. Create your permission sets. And yes, if it's not fully complete, you won't get fully penalized for it right now. But you'll be you'll move yourself into the B category, or maybe the A category. So that's my message. I guess the final message is: don't wait to move yourself into Path B or Path A. Because when you suddenly need the features of API 67 and above, you don't want this to block you using those features. Yeah, I think it also sends me a great message. If I haven't done the 67,
[37:46] then all the future new features I cannot have, right? Exactly. Yeah, you can't go to 67 and say, "Oh, I don't want default user mode." That doesn't work. Indeed. Okay. But thanks a lot, Andrew. I think we covered a lot. And how about your future role? So you started your consulting role, right? You are a one man company, or yeah, yeah. For me, at the moment, I do partner work closely with my clients, developers, and leadership, and so on. But yes, I'm not planning on building Andy in the Cloud Consulting to be the next SI, you know, mega company or anything like that. I'm quite happy, kind of doing sort of bespoke consulting in the range of what I discussed earlier at the head of the call, and it suits me just fine right now. So, yeah, if anybody wants to get in touch to to discuss anything we've talked about on this topic or Anything else that I discussed early at the top of the call? Then I'm on LinkedIn. Just approach me there, and we can have a chat. See how I might be of service. Yeah, thanks a lot, Andrew. I will put your LinkedIn and the blog post link. Thanks a lot, and you very much. See you next time. Bye bye. Thanks everyone. Bye bye.
