Salesforce errors are inevitable.
But how should you deal with them, especially as the platform becomes increasingly mission critical?
In this featured webinar hosted by Apex Hours, two top Salesforce experts survey the best ways to identify, manage and resolve Salesforce errors, taking you beyond its out-of-the-box tools into robust options that make troubleshooting easier and more effective.
You'll learn the pros and cons of using free open source solutions like Nebula Logger; external platforms like Splunk and Datadog; the free native solution from Pharos; and other logging and observability options, so you'll have a better idea about which solution best fits your situation.
Below is a transcript you can use to review topics from the webinar that interest you, complete with links to elements referenced.
Indexed Transcript of Apex Hours Webinar
Amit Chaudhary:
Good morning. Good evening. Good afternoon, everyone, based on your time zone, welcome to Salesforce Apex Hours. My name is Amit, and today we are going to talk about, “From Logging to Observability.” So, I have two special speakers with me. Let me hand over to them for their introduction and introduction. And so, Nikita and Matt, I’ll hand over to you.
Nikita Prokopev:
Hi everyone. Thanks for joining us today. Let's get the intros out of the way here real quick. I'm Nikita Prokofiev, CEO and founder of Pharos AI. So my background is in engineering. I was a senior software developer at Salesforce for about nine years, worked on building the platform, then turned to consulting and wrote for the platform for about the same amount of time and, head up Pharos and run the product.
And helping me today is my good friend Matt.
Matt Kaufman:
Hi Nikita. Thanks. I'm Matt Kaufman. I've been in the Salesforce ecosystem for 22 years, primarily as a consultant, but also as a developer, technical architect, trainer and more. Thank you for the slides. I've written Salesforce for Dummies, as well as Learning Apex Programming, and some online courses as well. And so, yeah, this is a topic that's near and dear to my heart.
Nikita:
All right. Thank you. Matt. Just to let everybody know, we're going to be collecting your questions in the chat as we go. And we'll get through as many as we can at the end of this webinar. So please feel free to voice your opinion. Love to hear it. Now let's go ahead and get started.
Salesforce Has Become Business Critical
So, I wanted to talk about why we're all here today discussing the topic that we're very passionate about.
I'll start with a little story here. So, in my consulting days, probably about ten years or so ago, I noticed that Salesforce started to turn into much more than a tool for salespeople. It wasn't just a Rolodex; it wasn't just leads and opportunities. It was a lot more. And basically, it started to become increasingly business-critical in all organizations, large and small.
Now, this is largely due to the platform becoming more sophisticated and mature. After all, it's always convenient to have a one-stop shop for all of your business operation needs, rather than have multiple siloed systems talking to each other. So, that's kind of what I've observed. Now, there's a lot of customization to meet this need, you can't just use out-of-the-box if we want to run our entire business on it, right Matt?
Matt:
You know, the stock ticker is CRM. And if you go back in time, that's what Salesforce was. There was some sales functionality to it as well. But if you think about just keeping track of people, you probably don't have a lot of moving parts. It may be critical to keep track of those people, but there wasn't a lot of business logic.
There wasn't a lot of automated functionality. It was just a simple database. And at some point, Salesforce grew from just CRM to really a platform.
And then, that platform has all sorts of functionality built into it, and then enables you to customize it with automation, whether it's declarative or code. And you have integrations with a lot of other systems, both sending stuff out of Salesforce, but also, things coming in from outside systems.
And so we have all these different moving parts now. And it really — kind of like you said, Nikita — it's become a critical system. You know, what was once this silly sales tool that was better than people keeping track of things in a notebook or business cards on their desk, now is this business-critical system used for all sorts of functionalities.
I think most of the time that I get involved with a project where, you know, some type of architect need is needed, it's not keeping track of sales. It's totally unrelated. In fact, it's other business processes. It's things that you would build on a general database platform. And that's really what Salesforce has become.
So, to me, when something goes wrong, it's not just, “oh, I don't know Nikita's phone number” anymore, because of course I have your phone number. It's in my phone anyways. It's in my email. That's not a critical use case to just keep track of phone numbers. But if I can't send you a quote or if I don't have ERP information flowing into Salesforce, then I might say the wrong thing.
We may take the wrong action. We may turn off your licenses when we weren't supposed to. Right? And those are really more mission critical than the days 20 years ago when I started, where it was a nice to have.
Nikita:
Yeah, absolutely. So why? yeah, I guess going back to the why here, why is it so hard to manage this growing complexity? And the reason for that is, you know, Salesforce has a lot going for it. Love the platform. Most of us here, it's our day-to-day, right? We build on it all the time with customized extended.
But why is it so hard to manage that observability aspect of it? Well, the answer is we're essentially driving a fancy car and we don't even have a dashboard on it. So, we don't know how fast we're going. We don't know if the engine's overheating. We don't know if we're running out of gas.
All these basic things that we're so used to, the platform just doesn't deliver on that. Now, there are some out-of-the-box tools and we'll talk about those. But they are not sufficient for this business critical stuff that we're dealing with today. So, you know, that's the basic premise here. And, as I went through my journey and Matt went through his journey, we realized there are five distinct paths that folks can go down, typically, to address this problem.
And so we're going to talk about those five paths. And, I just want to get one thing out of the way, right from the get go: one of those paths is Pharos. So, we're going to be talking about Pharos, which is my product. So obviously I'm biased. I have built it to address a lot of the Salesforce scenarios that we're going to talk about.
But at the same time, I realize it's not the best option for everybody. And so, what I'd like all of you to get out of this today is that you have options, and we're going to try and cover a lot of them.
We won't be able to get in-depth on a lot of them. I mean, I can rant about each one for hours. But with the time that we have, we're going to do the best that we can to cover everything so that you can do your own research. We encourage you to go out there and learn on your own and make the decisions.
Now, we are also going to be publishing a comprehensive white paper after this webinar that you can get by following me or Pharos. We'll be sure to send you a copy. It's going to have a lot more detail than what we'll cover today. And it's going to go into some of the engineering gotchas as well. So look out for that. We look forward to sharing that with you.
Managing Errors: The Five Paths You Can Take
Now let's talk about the five paths that I mentioned. What are your options?
So, I'll throw the first one out there. And we've kind of touched on it a little bit. And that option is out-of-the-box, aka “do nothing”. Right? What this means is you have no logs saved anywhere other than, you know, you've got the dev console, you've got the debug logs, you've got the exception emails. So you've got those tools available to you, but you don't have anything else.
What you're stuck with is the defaults and people and processes. And that's the first option that we're going to touch on. I think it's important to cover it because it gives us a bit of a baseline to compare and contrast the rest of the stuff that we'll be covering.
So, option number two, Matt, what do you think should be on this list?
Matt:
It would be the exact opposite of doing nothing or, you know, using out-of-the-box. And that would be building something yourself, which I've done many times over the years. And it always seems to be a little different. As you explore the requirements, it starts to get more and more complex, and you realize you're building an entire application just to keep track of your application.
So it's a lot of work, but if you have in-house experts who are Salesforce admins and developers, it's a natural place to turn to, where, you know, “oh, we already have Salesforce. Let's build it there.” And so that's usually what we do. We start building out objects to keep track of the logs, and then functionality to record it.
And then maybe you have reports and dashboards and things like that. But it's extra work. And like I said, you're basically building out a whole 'nother application, and it's kind of —you're doing it on the side. Your job is not to build out tools to keep track of your logs. So, that would be option two to me.
Nikita:
The other is exactly what you do.
Matt:
Yeah.
Nikita:
Yeah, yeah. Perfect. So DIY is a really common option that we see people travel down this path. There are lots of reasons why people do that. But in our practice, we were able to distill it to two main reasons:
One is people just don't realize they have other options. And so they go right into the build.
Reason number two, and this is somewhat popular in certain organizations, is that sometimes there's a strict “no third party” policy, where you can't get any tools, you can't do anything. You have to build everything. You have to reinvent the wheel for anything you want to get done, including observability. So, yeah, option number two is DIY.
Just to set the stage here, what we're going to be talking about is—we're not just going to be talking about logging, right? Logging is great and it's the foundation for observability.
But what we seek is a little bit more than that. We'd like logging. We'd like some notifications. Right? We want to receive timely notifications in, say, Slack or Microsoft Teams.
And we want some semblance of analytics. Right? We don't just want to have the data. We want to be able to look at it. We want to try and get some insights out of it. So our MVP, as we'll call it, is logging, notifications, and analytics.
So I'll throw out option number three, which is gaining popularity, and that's open source. Guess what? The larger community has come up with a lot of cool tools for you guys to use, starting from the logging framework. So, there are tools like Nebula Logger, RFLIB, a whole bunch of others, that you can just plug into your org and start utilizing. There are also tools like Grafana, which is an open-source observability platform. It's not on Salesforce, but it's still open source. And they have a free tier. So that's another great option for your visualizations, for your analytics and notifications too.
And there are other tools that kind of solve different types of monitoring problems. Like, for example, sfdx-hardis— you may have heard of it. It's a really nice one for change monitoring. So if you have 15 different sysadmins in the org making changes, you can stay on top of that.
It also does some metrics capture for you, like governor limits and license usage, that sort of thing. It's a really nice tool as well. We'll talk about it a little bit.
So that's the open-source option. The larger community has graciously given us these applications and these utilities.
Matt, what do you think is the next one after that, that we should talk about?
Matt:
Yeah. So, the opposite of open source would be commercial solutions that exist off the platform. I go to a lot of conferences, both Salesforce and non-Salesforce ones. And for years I think we've seen these applications at the non-Salesforce conferences, apps that could monitor your virtual machines and run at the LS level and things like that.
With Salesforce, we don't have the ability to install those apps. But now, in the last couple of years, I've started seeing booths from these companies at the Salesforce conferences and what they have is ways of either connecting to Salesforce, where there's some type of app or it's just their APIs—Splunk, Datadog, New Relic, Log Rocket, there's so many of them.
I have socks and hats from them all. But they've realized that there's this gap in the Salesforce space. And so they've made it so that their clients who are already using the tools could work with Salesforce as well. So I think that's the opposite of open source. We'd say it's the commercial apps that are running off-platform.
So they're not Salesforce specific, but they do provide this logging or monitoring or observability functionality. It's just their focus is more general breadth than one particular platform.
I think we're down to the fifth one, right Nikita? You want to take that one?
Nikita:
Yeah, we're down to number five. And that is the native option. So, your native observability platform.
Currently you've only got one option out there, which is Pharos. So let me clarify what we mean by native here. Native means that it's fully encapsulated into the platform. It's built using the platform’s technologies.
Your data originates in your org and it stays in your org. It's not processed anywhere. None of that's happening. Now again, I'll say this, Pharos was built to address, specifically, Salesforce challenges and some of the shortcomings of the platform that we'll see as we go through our discussion here. But again, we realize it's not the best option for everybody. We’ll mention those caveats as we go along.
All right. So those are our five options. Now, how are we going to look at them?
Evaluating Your Options: The Criteria
Well, it's good to have a bit of a criteria framework in mind when evaluating each one so that you can be objective and check all the boxes. And we've come up with this criteria framework that we think is fairly universal.
And the other good thing about it, is that it can help you have conversations with your management—and their management—when you're arguing for observability within your company.
So I'll throw out the first criteria here, which is probably the most obvious: We want to talk about key benefits, right? What does the solution offer us?
What kind of features and functionality does it have? What are the use cases that it helps solve? What is it good at? What is it known for versus what's on paper? Because sometimes things are advertised, but, you know, that solution is known for something else. So, we'll cover the key benefits here.
Matt, what's the next one on your list that you think is important?
Matt:
Security is always important to me. I've built apps for the AppExchange and I always get concerned when data is flowing out of the platform.
You know, we usually have to get IT, and legal sometimes, to bless us using Salesforce as the place to store mission critical data. But then we go in and we install an app—where maybe the data goes elsewhere—and we just rely on the contract to make sure that things are correct.
But I like to have a little more control...maybe that's an issue I need to work on! But I would like to know, where does the data go? How does it get there? What's the mechanism involved? And does it have the same level of security control that Salesforce has?
We have a great security layer in Salesforce where we can control things: the field level, the object level, the record level. And so those are things that I usually want also, when we do use apps. Because we use a lot of apps, I want to make sure that I can have that same level of control and allow managers to see certain data, individuals to see smaller amounts of data. But maybe some executives get to see everything.
Nikita:
Yeah. So that's really important. In fact, for some organizations, I'd argue the security moves up to the top of the list, because there's certain compliance and requirements that, if you don't meet those, then the tool's out the window.
Anyway, so let's move on. The third one for me would be implementations.
What is involved in rolling out the solution? We want obviously to know what kind of expertise is required. Who needs to be involved? What kind of resources? Do we need devs? Do we need architects? How many? What's the shortest timeline to MVP? Because we want to see value right away. Right? Or as soon as we can, especially if we have immediate pain that we need to address.
If the solution is going to take us a year to roll out, it just really doesn't do us any good. So implementation is very important in our considerations.
Matt, what's the next one for you?
Matt:
Yeah. So, price. I mean, ironically, I'm technical, so usually I'm giving options on pros and cons for technical purposes. But one of the things that I almost always focus on is pricing and making sure that it makes sense to do something. I look at the subscription costs—typically apps are going to be now all subscriptions. So are we paying by year? Are we paying by the org? Are we paying by the user? Is there a cost-per-click as well? A lot of new apps do that.
And then there's also the investment in getting an app up and running. So if we're going to build out some type of solution, we might have to factor in, “Well, what's the time involved and what were those people normally doing otherwise? Or do we have to hire outside consultants to do it?”
So it's a combination of the hard costs for the licensing, but also the softer cost of getting us to the point where it's working.
Nikita:
Yeah. And my last one here is going to piggyback off number four. And it's what we call total cost of ownership, or TCO. So this is an all-encompassing metric that gives you an idea of, what does it cost you as a company to own the solution long-term? Not just to roll it out and pay the subscription fees and what-not.
It's also talking about things like adoption, risks, continued maintenance, things like that. So we'll look at it from a larger time frame—three years, five years, five-plus years.
So, this last one is important, because we want to build for long term. We don't want some piecemeal stuff. We want this to last us.
Now that we've talked about the criteria, let's move on and look at our respective options and evaluate them through this framework.
Evaluating Key Benefits
Let's go through the key benefits of all of these approaches.
I'll start with “do nothing.” That's the most popular one today, believe it or not.
A lot of companies are in this bucket. And I guess you have some key benefits there. It is advantageous to do this for certain companies. You can focus on your day-to-day. You don't need to maintain anything. You just kind of take things as they come. There aren't any immediate expenses, so you don't have to pay anything.
If your cash flow is not that great, you don't have to worry about shelling out stacks of cash for tools. You can manage it with people and processes up to a certain point. So there's that. It can work for you. And we'll talk about where it's applicable.
Matt:
You're right.
It is probably the most widely used technique. I don't know if I'd say it's popular, but it is definitely the most prominent. But it's just this huge risk. You know, at any moment, something could stop working and grind your Salesforce to a halt.
Nikita:
Yep, now you're all-hands-on-deck.
Matt:
Yeah, that's the thing. So, I think it's all cons. I know that it sounds like there's a lot of pros to it, but it really is all cons.
It's the same reason why all of us typically have auto insurance before we start driving. If you're a homeowner, you have homeowner's insurance. If you're a renter, you might have renters’ insurance. You know, medical, dental...you can't not have something there just in case. There's just too much risk.
Nikita:
Yeah. Yeah. I agree with that. And we'll talk about that during our discussion of TCO and implementation, things like that. So yeah, definitely watch out for that one.
Okay. DIY. This one is, to us engineers, it's obvious, right? You basically control everything from end-to-end. It's a fun project, where you're the decision maker on the requirements, you're the end user, so basically you own the entire lifecycle of this project. So those are the pros.
I think the first one is probably the biggest one and why it's so appealing to engineers. Because you know everything there is to know about this. You can control everything. You can build it however you like. So it's great from that perspective.
Matt:
Yeah. But then you also run into this—because, like I mentioned earlier— where it becomes an app upon itself that you now have to maintain. So instead of worrying about the requirements that you're supposed to deliver for your business users—you're not delivering requirements for your internal Salesforce team. And so that can be a big time sink and typically resources also.
Nikita:
Absolutely, absolutely. Okay.
And then the open-source option is, you know, you've also got a lot of functionality on that one. A larger community have built us a set of tools. Take Nebula Logger. It's a really powerful logging framework. It's got all the things you could possibly want. And realistically, could possibly ever want to build on your own.
Can you do better than Nebula? Perhaps. But, you know, why? Why do that? Why reinvent the wheel, right? Same for Grafana. You've got that great observability tool. You might as well leverage it.
Now, again, it's also a lot of fun putting these tools together. It's kind of like Ikea furniture. You can combine things and you can get a whole stack going, get them to interact with each other if you need to. Plus, the community's amazing. The people that are behind this are very knowledgeable, amazing to interact with. So it's a good option from that perspective.
Matt:
I agree, the community can be amazing with open-source projects, but I've also worked with some open source projects where you run into a problem and you just hit your head. And if you ask the question wrong, people get mad at you for asking it wrong. Or they say, “read the docs.” And so, it can be difficult to start working with a project that you're not familiar with.
Nikita:
Okay. Fair enough, fair enough.
Moving on to off-platform here. Now, the main advantage here is that these tools that we talked about—so just to throw out some examples like Splunk, Datadog, you've got New Relic—these are very scalable and very robust tools that have been serving other parts of the technical stack for years and years.
So now take that technology and add Salesforce to it. And now you've got something robust and scalable. It's professionally supported, so it's got that going for it.
Matt:
Yeah, but they're paid products. They're these huge platforms. And if you're using it for your entire code base—not just Salesforce, but everything—you really almost need a team of people or at least designated folks who are responsible for it and for maintaining it, that type of stuff. There's a learning curve. It's not as quick as it sounds.
Nikita:
Yeah, absolutely.
All right, on to our last option here. In terms of key benefits, what does native observability give us? or namely Pharos?
Well, I think the biggest pro here is that we can get really quick time to value. It's very easy to set up and get going and you get value right away.
It's democratized. So, not just developers benefit from this. All the other stuff that we talked about is typically kind of in the dev role and we don't see a lot of adoption outside the dev circle, which could be a problem. We'll talk about that later. With Pharos, you don't really get that. It's a tool for everybody.
So, yeah, it's... Go ahead, Matt
Matt:
I mean, obviously you're biased. So I'd say that the downside is that, you know, it is Salesforce-specific. And so, if you did want a tool to monitor your entire stack, you probably would use one of the commercial options that we just talked about instead. So that's, I think, the downside to it, to be fair.
Nikita:
Yeah, I agree. It is meant for Salesforce, at the end of the day. You could get other stuff in there if you want. But, you know, that's typically not what people do. So fair point.
Okay. Moving on to the next one.
Evaluating Security
Let's talk about security from the security perspective. How do these options stack up?
Nikita:
So, “Do Nothing,” Matt—what do you think? Is that secure?
Matt:
No, obviously. I mean, your data is not going anywhere. So in that sense, yes. If you were to just look at a checklist.
Nikita:
Because you don't have any data...
Matt:
It is very secure to not collect logs. There's no chance that that log data gets exposed and no chance that you have credit cards or Social Security numbers being exposed in the log data. So, yes, it's the most secure way to do observability in a nutshell.
Nikita:
You don't have to worry about data if you don't have any. So it's as simple as that. But of course, with this option you've got that added risk. So, you can have a problem in your system that can expose vulnerabilities somehow. It’s indirect, but it's happened.
There are other risks associated with it that we'll talk about. But yeah. Anyway, very secure option.
Let's move on to DIY. So Matt, what do you think about that one…it seems like this one is pretty secure, right?
Matt:
Well, if it's done properly and you're building it yourself, then yeah, it can be secure. Like I said, we have a great security layer in Salesforce where we can control who sees the data and what, what records they see, and all that kind of stuff. So it can be very secure when done properly. You do run the risk, of course, that your admins might be able to see things that end users can't, but they're going to be able to see it either way, right?
If you're an admin of Salesforce, you probably can see the data, whether it's in a log or the actual data. So I think it is secure.
Nikita:
Yeah, fair enough. And then if you are doing integrations and you want to have other tools off-platform and part of the DIY, then yes, you're running a larger risk there. But if you're building on the platform, you should be okay as long as you think about access control. So that's the important part here.
Now in terms of open source, this is where things kind of get tricky because you've got so many tools in this open-source stack. And depending on which ones you use, your security profile might vary.
So for example, if you're just using Nebula out of the box with their notifications and the logging framework, it's all native, right? So you really don't have that much to worry about. They've got built in security controls.
Now if you're using Grafana, on the other hand, that can pose some risk because now you're going off-platform.
If you're using SFDX-Hardis, you're going to have to host it somewhere. So, you know, you can't just run it off your machine. You might want to plug it into your CI pipeline. So, you've got some integrations going on there. Again, increasing that risk.
So all in all, if you stayed on the platform, I think that's the rule of thumb here, you'll be okay. Once you start going outside, you start running additional risk levels.
Now, let's talk about off-platform here, real quick.
Matt:
Yeah, I mentioned it before. Obviously, I always get nervous when things go off-platform. Obviously, we have to get IT and legal to typically buy in too, but unless you really know a lot about that platform, you don't know what's happening with your data. You don't know what they're doing in terms of security. It seems like every month there's some type of new item in the news about a breach somewhere.
So I get really nervous about sending any of our Salesforce data off-platform. The same can be said for open source if it's being hosted, too. So it's something to keep in mind for both of those options. but yeah, if we are going to send stuff off-platform, we need to be able to trust that company.
And then we have to make sure that people who have access to that app, that they have the correct security controls too, like I mentioned. But now it's more work, right? So we had to secure Salesforce. Now we have to secure this other platform too. So we really need someone who's going to be an expert, or a team of experts, to manage those platforms.
Nikita:
Yeah, absolutely.
Matt:
I don't take it lightly when someone says that they're secure. I want proof.
Nikita:
Makes sense!
Okay. Let's talk about native observability here. You know, on this one, data is not leaving the platform. Like we said, it's native. So you're good from that perspective. There are access controls similar to what Nebula offers. You can control who sees access, who sees what on logs. All of these things.
Matt? What's your take? I don't want to talk about my product too much here.
Matt:
Yeah. So you make a good point. you're taking the advantages of having an off-platform app that is run by a company whose sole focus is doing the observability. But you're leaving it on the platform. So you kind of eliminated my bias about security and being concerned about stuff. Because if you're using Salesforce already, hopefully you trust Salesforce to host your data.
And so you should trust them to host the logs about that data and about any interactions on the platform. Then, like I mentioned, all the security controls if we're using objects. So I can now—my system administrator can configure sharing rules and configure profiles and permission sets. That's all within our capabilities.
We don't need to learn anything new. So, yes, you have a lot of pros and positive aspects there. That's a good point.
Nikita:
Yeah. And, I'll just throw it out there. You know that we, Pharos, are an ISV on the platform. We're on AppExchange, so we're bound by certain contractual obligations to provide a secure solution. So, know that being on the platform as an ISV does carry with it some degree of responsibility.
Evaluating Deployment and Implementation
Okay. Now moving along to implementation.
Nikita:
This is one that, I think, deserves some attention. So, in terms of do nothing, I mean, Matt, what do you think what kind of implementation are we looking at here? Yeah.
Matt:
Yeah. Costs you nothing. Zero time, I can have that that project done for you today.
Nikita:
Beautiful. Well, you're right. There's no technical implementation, right? There's no tools. There's nothing to implement, to buy, whatnot. But you have to worry about people and process, and that's something that you can put in place to kind of alleviate the pain that you may be suffering with the out-of-the-box stuff.
That could take a long time to build, especially if you don't have the right resources at your disposal. You also—if you don't know some of the out-of-the-box tools, like you don't know how to read debug logs and things like that, that'll slow you down. There's a learning curve there.
Those tools are not easy. And not many people will be able to learn them very quickly. So just keep that in mind if you're in this position. You can supplement with people and process, but be prepared to spend some time on it.
And, really, the bottom line here is that this solution is really not sustainable long-term. You can build the processes, but if anything changes, your processes go out the window. You have to start from scratch. It's just a lot of hassle.
So, let's talk about DIY.
I'll just throw out a disclaimer here quick. If you've got admins on your team or if all your team has is admins, don't even go down that path. You're not going to build a logging framework. You’re not going to be able to do that, to support it. So, we're assuming you've got a team of developers and you need to build a logging framework.
Now, building a logging framework is harder than it sounds. Because there's a lot to it. You've got to build it in a robust way. You've got to make sure data persists, that transactions don't get rolled back. You've got to worry about Apex. You’ve got to worry about LWC. You got to worry about Flows.
There's all these things that you need to worry about. And, you know, you've got to design proper interfaces for your classes so the rest of the team can use it effectively.
There's quite a bit to think about. You know, you ideally would get an architect involved, you even need to think about data models. So, there's a lot involved here.
When we're talking notifications, then things even start getting more complicated. Maybe with Slack you can integrate a bit easier because it's sort of now part of Salesforce. Right? So, you know, it's there. There are some cookbook recipes that you can follow.
But really, even with that, you have to worry about security. How are you going to store those authentication tokens, things like that?
If you want to do Teams— Microsoft Teams—because your company's not using Slack, that's even harder. Now you've got to integrate with those APIs and they change. Right? So you've got to factor in maintenance. You've got to learn those APIs. You've got to build that integration, again, worry about security, storing the auth tokens and things like that. There's quite a bit there.
Now in terms of analytics, things are a little bit easier. You've got the native analytics. If you don't know how to use them, you'll probably learn very quickly. Again, from a technical perspective, analytics are not hard. But from a functional perspective, they're a lot harder. These views will have to give you the right insights.
And if you don't build them the right way, then it's just not very useful to anybody.
So, in terms of DIY, I'd put it at 3 to 6 month for an MVP. And that's on the conservative side — assuming you've got the right team and you can dedicate time to this project uninterrupted.
All right, now let's go to open source. I want to move things along here.
Matt:
There's a lot of different options for open source. It's hard to put a set timeline on it. I know, I'm a consultant, so that's not the answer people want to hear usually. But it really is going to depend on what packages you want to implement. And it may be multiple, and more importantly, what your experience is with those packages. Because it's like I mentioned earlier, if you don't have a lot of experience with open source, you're kind of on your own to read the docs.
You can ask the community for questions, but there's no one you can, you know, go back to the company and say, “I need support.” And so the timeline evolves. It can take a while, and if there's hosting or other more advanced functionality to it, it'll take even longer. So yeah, I think that you're right there, you know, 1 to 3 months for an MVP.
Definitely something that can be done, but realistically, for a system that you can rely on, it could take up to a year, depending on whether you have dedicated resources or not.
Nikita:
Yeah, absolutely.
Now let's talk about off-platform. So, this one seems like it's easier on the surface of it. But there are some caveats there.
Off-platform tools like Splunk, Datadog, and New Relic, they're really good at ingesting event monitoring data. So if you've got that extension or that add-on from Salesforce event monitoring, you can get started fairly quickly.
And when I say fairly quickly, it's still probably going to take you about three months, or maybe up to half a year, and so you'll get some value out of it in a fairly reasonable amount of time. But if you're not using event monitoring, this is where things start to get more complicated.
Now you have to get your own logs. How do you do that? Are you back to that question of, “okay, we need a logging framework. We need to get our logs going.” Do you have to build that?
You'll have to implement it across your entire code base. Remember, if you don't have logging in your code or anywhere, you're not benefiting. Just having a logging framework doesn't do anything for you.
So, yeah, it could extend well over a year, if you need to do that, if you need to do those integrations, if you need to implement logging.
Matt:
Integrations are complex to design. And then logging of integrations, which require integrations themselves, would be even more complex. So, I think you're right on that one. It's over a year to be safe.
Nikita:
All right. So...
Matt:
That leaves us with the last option.
Nikita:
Let's talk about the Pharos option here. Now, there's a couple things there. If you just drop Pharos in and configure it, you could do it within the same day, and you'll get immediate value. So that's the good thing about it.
Now, if you do want custom logging or, you know, “hey, I'm going to add this to my Apex class, I'm going to add this to my LWC, I want to do some profiling,” then you're looking at some implementation time frame depending on the size of your code base.
But, it's very quick to get out-of-the-box automated error tracking, as we call it. And you'll get a lot of benefit just from that. So it is quite efficient from that perspective.
Now, let's move on.
Evaluating Pricing Options
Let's talk about the Price. This criteria here.
Nikita:
So, Matt, what do you recommend?
Matt:
I wouldn't recommend “doing nothing.” But obviously, it really costs nothing up front to do nothing. So that's going to be the easiest one to get approved, I guess, if we had to go to get approval. No upfront expenses.
Nikita:
Yeah. But you do have to worry about risks. And those are kind of hard to gauge—what those could be and what those could cost you. But do be aware of that. Otherwise, nothing on paper that you have to pay for. And same for DIY, I'd imagine.
Matt:
if you have the resources already in-house, then yeah—if you have developers in-house and they have the bandwidth, then it costs nothing. You're already paying them anyways. They might as well build something out.
Nikita:
Yeah. So you'll have some steep investment in dev from the get-go. But otherwise, you don't owe anything, there are no invoices to pay. Keep in mind that you will still have to do maintenance and so on and so forth.
Now let's talk about open source. Seems like that's somewhat similar.
Matt:
Yeah. Typically, open source is—we call it “free” software. It's not necessarily truly free. But there usually is no licensing cost. If hosting is involved, then you'd have to probably pay for the hosting on some infrastructure or platform. But the usage of an open-source product for commercial purposes often—not always—often has no cost.
Nikita:
Yeah. Agree.
Off-platform. Matt, why don't you give us your experience on some of these? I know you've looked into that.
Matt:
Yeah. Like I said, I see them at the conferences, and so I've had conversations. I went to a website earlier today, and I went to the pricing page and it basically just said, “contact us,” which I cannot stand. I need to know—before I contact you—is it even worth my time? Are we in the same range? That type of thing.
I saw another one where they did provide pricing, but there were 50 different products and each one had different pricing, and there were options. And a lot of it was usage based. And I couldn't tell from looking at it what this would cost. I also didn't know which products I would need, to be honest.
Nikita:
Yeah, I think they're gearing their pricing towards the enterprise more because, you know, these tools, it sort of makes sense. So be prepared to talk to a salesperson. They're going to have to do discovery. You're going to have to tell them what you want. And then they're going to try to find the best pricing model that fits you.
It's still very hard to gauge upfront costs.
Matt:
At the enterprise level, what I often find is the pricing on the website is not the price they pay anyway. They get a custom contract, they're paying something totally different.
Nikita:
You will have to negotiate that, yeah.
Matt:
Yeah, it's very difficult to do an apples-to-apples comparison by looking at the websites.
Nikita:
Yeah. Now, one thing I'll say from experience is that if you've got other parts of your company using a tool like Splunk or Datadog, it's easier to roll into that for your Salesforce stuff, and it'll make more sense, pricewise. But if you're standing it up just for Salesforce, it'll probably run up a tab on you.
All right, let's move on. Talk about native observability.
Matt:
Nikita, I’m glad this is coming up, because there were some questions in the chat about Pharos and how you do the pricing. So maybe you can tell us that.
Nikita:
Yeah, absolutely. So the way we price is, it's really loosely based on work size and complexity, right? The premise is that the larger your org, the more complexity you have; the more users, the more you have to worry about in terms of risk and so forth. So larger orgs pay more, smaller orgs pay less.
That's kind of the basic premise. Now we do have tiered functionality available. So, you know, if you're not a sophisticated team with a lot of processes and whatnot, you can get the basic edition. We've got higher tier editions where you go, “okay, I gotta integrate with bug trackers. I've got a DevOps process.” You can leverage the higher tier editions.
And also, we have a free tier.
Matt:
Thank you. I was going to ask. There's a bullet there that says, “free tier.” Can you tell me more about that.
Nikita:
Yeah. So, free tier is available. It has some limited functionality, mostly around visualizations and custom charts. So we're not going to show you the fancy visualizations, but you'll get the automated error capture. You can get those exception emails in your org as logs. You get the issue tracking. You get the logging framework, which we're calling Triton.
So it has very much the same capabilities as Nebula. You can do your custom logging, you can do the automated error capture. You just don't get the fancy charts. That's basically, I mean, there's a lot more that I'm not mentioning here, in terms of additions, but if you have any questions, I'd be happy to answer that.
Assessing Total Cost of Ownership (TCO)
All right. Let's move on and talk about the TCO metric here.
Nikita:
So just to recap, we're talking now long term. We're talking about owning the solution, maintaining it, supporting it, adopting it. What are all the costs associated with that? Now, in terms of “do nothing,” Matt, I'll let you take that one. This is your favorite, I can tell.
Matt:
So, ironically, I think this is the most expensive option. If you're doing anything in Salesforce that's critical to your business, doing nothing costs you zero upfront. But the day something breaks is when it's going to cost you a lot more.
It's going back to that insurance analogy. I think that it's silly to invest a lot of money in Salesforce for the mission critical processes of your business and then not ensure that, when something goes wrong, you're able to quickly recover.
So this, I think, has the highest cost of ownership.
Nikita:
I agree. You know, it's just not sustainable. The moment something breaks, this is where it can roll back all of your savings on tools and processes and other things. And you're just back to square one.
Okay. What about DIY? It should be better, right? Because you're actually trying to solve the problem there. You're doing something about monitoring and you're logging, you know, all these things.
Matt:
Yeah, I think there is some curve that we could probably chart out. If you're a large enough company that has a lot of Salesforce resources, it might make sense to DIY a solution in-house because, across all of those resources, there'll be enough bandwidth to build out this application and maintain it. Ironically, though, if you're that large of a company and you have that many resources, that much budget, you probably already have a commercial application anyway, and so you wouldn't DIY it.
So, the problem is, it's tempting for smaller players, smaller customers to build it themselves, but then the cost is actually higher, because now that developer who should be working on something that's mission critical is actually working on the observability.
Nikita:
Yeah, there's an opportunity cost to it.
Matt:
And you run the risk that there may be a bug in your observability functionality that you built out, and now you have to figure out two things that can go wrong, not just one.
Nikita:
Yeah. What we've also seen with this one is people tend to drop it halfway. And it's a real shame because you've invested a lot into getting a solution there. And then, something happens. Priorities change. You get pulled off onto other things. And now you've got something that's sort of half-baked, not really usable.
So it just sits there and slowly degrades and nothing comes of it. So make sure, if you're going down that path, you have uninterrupted time to work on this and get it right. But, overall, in terms of the dollar signs, we’ve got this kind of Yelp-style scale here going on.
So, you're still better off than to do nothing because you are doing something here. But the maintenance and development aspects will drive this up for you.
Now in terms of open source, again, it's somewhat similar to DIY, right? Wouldn't you agree, Matt?
Matt:
Yeah, your DIY-ing with somebody else's code as a starter point. So it's a kind of a way to jump ahead. But you have a learning curve then to learn, okay, how does that functionality work? How does that toolset work? And so again, you're taking away time from doing your actual job of developing for Salesforce, for your business processes, to learning about these other tools and how they work and adjusting as they change over time.
Nikita:
Yeah. Yeah, absolutely. The other thing worth mentioning here is—what we've seen with companies that go the DIY path, or the open source path—is that people will, you know—certain developers will learn this tool inside and out. They know everything there is to know about it.
But then, they transition. They move on, they get promoted, or they leave the company, or they go on vacation for a month. Right? And then, all of a sudden, now you have nobody to manage this application that you have.
And so adoption-wise, this one's really tricky to get right. If you're doing this, make sure your entire team is behind it, they know what's involved, they know what these tools do.
I mean, learning something like Grafana, as powerful as it is—and actually, because it's so powerful—it's going to take you some time, you're going to have to learn their query language. You're going to have to learn how to build those visualizations, those monitoring rules, and you have to maintain them and fine-tune them.
So while there's not a cost associated with building these tools, as in our previous option, there is a steep learning curve and some adoption issues that you will have to work on.
But overall, in terms of dollar signs, I give it a two out of four. So it's not a bad option.
Let's talk about off-platform.
This one seems pretty obvious. These tools are not cheap. Just to be frank about it, they're meant to serve the enterprise. They're scalable, they're robust. They have to provide you support. They do take care of the hosting, so you have got to pay for that.
Also, same problem as—well, not “problem,” but, you know, same issues as with some of these open-source tools. You've got to learn how to query Splunk. You've got to learn how to query Datadog. Those are proprietary technologies that you will have to read about and really invest the time into getting up to speed.
And again, you've got to have adoption in mind, too. Is it just the one developer that's going to get insights from that tool? No, you should get your entire team trained up on it. So there's a lot of training investment. And, you know, you've got to do knowledge transfers, things like that.
I would say this one really makes sense if you've got other departments using it and you're rolling into that. That way you have some shared expertise already within your company that you can benefit from.
And also, from the pricing standpoint, it's not as steep of an expense upfront. Now, in terms of Pharos, I'll talk about that one. It is nowhere near the price of Splunk and Datadog. Again, it scales proportionately with the size of your org. But, you know, if you're investing more in Salesforce, you should be investing more in observability, because you've got to mitigate that risk.
The biggest thing about it in terms of adoption is it's democratized. Pretty much anybody can use it. You don't really need to train people on how to query it because it's all standard Salesforce. You could build reports and dashboards. You know how to use the standard Salesforce interfaces to build list views and things like that.
So in terms of training and adoption, this is probably the least cumbersome of all the options. But anyone with a bit of technical knowledge can benefit from this.
Now if you are going the custom logging route and you're doing that, you will need to invest, and you own and maintain that. But it's optional.
Matt:
But someone could start with the free tier and then, you know, try it out for a while and then upgrade.
Nikita:
Absolutely. Yeah. You could start with a free tier. You could stay with the free tier, if that works out for you. You can also upgrade and your data will still be there.
Summary
All right, let's move on and summarize what we talked about.
Just real quick, I'll just kind of throw it out there, Do Nothing option...You know, if you have to do this, you'd better be a simple, easy org, right? No complex automation. If it’s just mostly out-of-the-box things, then you can manage that.
DIY, I would say, like Matt was pointing out earlier, if you've got a dev team and you want to embark on this project, and if you're under this no-third-party policy, which some companies are, then yes. You’ve got to make sure you have the technical staff. Then you can do it. Otherwise, just use the open-source tools. Don't try to reinvent the wheel.
Speaking about Open Source, this is great if your budgets are tight, and you want quicker time to value. And, you know, it's a fun project. If you want to be involved in the community, definitely explore that option. The larger community has done a lot here.
In terms of Off-Platform, like we said earlier, if you've got complex IT environments, it makes sense to roll Salesforce into that if you can. But be aware that this is not a Salesforce-specific tool. It’s general purpose logging, log analysis, log management. So you're going to have to spend some time trying to figure out how to query it and things like that.
In terms of Pharos [the native option], I think any size org really works for this. It's probably the quickest time to value. So if you have pain today and you want to do something about it, it's probably your best bet. But it can do a lot more for you than that.
Questions and Takeaways
So, yeah. let's see. I think we're, we're at the end of the hour, and our content here. So let's go ahead and go through some questions here. Let's see, kindly ask our moderator to drop us some questions into the chat.
Matt:
I have a quick one. I think I know the answer. But I have to ask. I've seen some apps where—and I mentioned this— I don't like going to a screen and it says, “contact us.” ifIf go to the app exchange listing right now, can I install Pharos in my org?
Nikita:
Yeah.
Matt:
Okay. Easy question.
Nikita:
Yeah, yeah. Super easy. Any other questions, you guys? Please send over.
Matt:
It looks like there was a question about pricing. Valerio asked.
Nikita:
Okay, we covered that.
Matt:
You covered that one already? They did ask, if there's multiple clients that they'd like to serve, can they buy on behalf of them? So it sounds like they are partners, a Salesforce partner.
You know, I'm a Salesforce partner too. I guess that's a good line of questioning. If we're a partner and we're working with a lot of different customers, do you have a partner program that we could work with?
Nikita:
Yeah, we do have a partner program. Absolutely. Yeah. Please reach out. We'll be happy to guide you, talk you through that. We have worked with a number of consultants and, yeah, there's a lot of value there.
Now, there was somebody mentioning that, “we considered using Scale Center but it doesn't have capabilities and sending notifications and limits.”
Yes, absolutely. That is the limitation of Scale Center. It doesn't—it's not the observability solution that we're talking about. It's—you can go in there and look and you see some immediate data, but it is not going to proactively tell you, “oh, hey, you're approaching this threshold,” and so on, so forth.
So if you want that capability, I'd say, try SFDX-Hardis. That will do some of that for you. Combine that with Grafana analytics. But again, that will take you some time to figure out. But that is possible. That's probably the closest thing I've seen to that.
Matt:
Here's another one: “You talked about the free tier, and I appreciate that you have a free tier. I think that's great. But if someone does have a need for the more advanced functionality, how do you recommend building that business case to management that they need to carve out some budget to either pay for licensing or implementation or whatever it may be?”
Nikita:
I think if you use the criteria framework that we presented to you, like, “What are the key benefits? What is this security wise? What does the price look like? What does the implementation look like?” I think if you approach it from that perspective, and especially the last one, the total cost of ownership, I think that would help convince your boss, like, “hey, we get immediate value, we get security, it's easy to own and maintain…”
Those arguments will be convincing to your manager, to your CIO, CTO, etc. And do mention risk. If you're not doing anything about observability, you're running risks. There are opportunity costs.
If you're going to be managing efforts like the “do nothing" approach, or you are going to be D-I-Y-ing, let them know that. “Hey, I'm going to need to spend some time on this project here. I can't do other things. So if you have some plans for me, let me know.” These are resource considerations that your management will take into account as well.
Matt:
Yeah, that makes sense. I mean, when it comes to risk, every admin has the ability to run the reports in their own Salesforce org and see, “How many opportunities did we closed this month? Well, what would happen if it took us a week longer to close each of those because of technical difficulties?” That type of stuff.
Matt:
That probably is a good place to start — running the metrics and figuring out how much more efficient we could be. But also, what's the risk if we were less efficient, and slowed down even?
Nikita:
Yeah. And oftentimes, if you talk to your team members, they'll probably share anecdotes with you, like, “hey, you know, remember this happened or that happened.” So you can collect those stories and, “hey, some of those could have been prevented. What did that cost us? How long did we spend troubleshooting that? How long did the postmortem take? What was the impact? Oh, we had to clean up six months’ worth of data. Oh, my gosh.” That right there is a red flag in a CTO's mind or a CIO's mind. Like, “Oh, that's not good.” Someone is saying here, “open source is best.” Yes. Open source rules. Definitely, great community, great tools. But like I said, do take into consideration the learning curve. The tools are evolving. Definitely a lot of good stuff coming out there.
Matt:
Yeah. I guess another good takeaway, as I think about it—we tend to talk with a lot of people who are just solely looking at Salesforce—admins, developers, architects, that type of thing. But the reality is, the allies are the business users, whether it's managers, directors, those type of folks who rely on you to build out Salesforce.
And so if you can convince them that this is something that you need to do your job better and support them more, then let them do the hard work of fighting for it. I think when a Salesforce admin says, “we need a tool,” the answer is, “nah, just go build it yourself,” you know, “that's what we're paying you for.”
But when a VP of Sales say that we need it, then, you know, that tends to get bought right away.
Nikita:
All of a sudden, things move quicker. Yeah. Also consider that we're talking about internal users here. But if you've got an external component—like a community (or experience cloud as they call it), that is user-facing, maybe running a support portal off of it, maybe there's a commerce portal or something—that is a critical, critical component of your stack and that's one that your customers will see
So not only are risks involved in security issues and things like that, but also, your reputation is at stake here. If your community is down or it's erroring out all over the place, people are going to stop using it, or it'll reflect poorly on you as a company.
Matt:
Yeah. So we only have a couple of minutes. And there's a question about PII and sensitive data. “I track sensitive data. How do you handle that with the logs?”
Nikita:
Yeah. So typically — I know Nebula does this, Nebula Logger, Pharos also has capabilities for it. It's very hard to separate out sensitive data from the rest of the log content at runtime. But what you could do is, you can mask that data out before entering the log into the database.
So this is what typically happens. You will come up with a series of regexs or rules, that say, “oh, if it's an email, just, you know, replace it with asterisks” or something like that, so that your logs are already sanitized. And then no matter where they go from there, things won't show up. If you're sending it off-platform or if your other users are looking at it, that data will be hidden.
Now, it may hinder troubleshooting for you, but you know, if your security team is adamant about this, this may be what you have to do. So that's typically how you handle that.
Because otherwise, you know, think about it. Separating the bit of sensitive information from your log is super, super hard at runtime. Like, “oh, I'm user xyz. I should be able to see this.” Building that system is complicated. None of the tools do this, to my knowledge.
Matt:
Okay. Got it. That's interesting.
Nikita:
New question. “Have in-house built error log and email notification based on customization. Will your product support out-of-the-box functionality, error logging as well?”
I think I understand the question. So you've built a customized error log and you've got emails going out when these logs are created. “Will this product support out-of-the-box functionality, error logging as well?”
Yes. Yes. The answer is yes. We have customers like that, that have done, you know, a little bit of DIY and they're leveraging Pharos successfully. So absolutely.
Matt:
I think there was one last question, but we're basically out of time, so we'll probably take it offline.
Follow For More Information
Nikita:
Okay. Yeah, we're at the, at the hour here. So thank you, everybody. Really appreciate you joining us. We will be getting that white paper out to everybody that's interested. Follow me or Matt , or follow Pharos for more content. Here's the details. We will be talking about observability, about logging, and about business aspects, engineering aspects. It's what we do.
Matt:
All right. Well, thank you so much, Nikita.
Nikita:
Absolutely. Thanks, Matt. Thanks all!