Salesforce, Inc. (CRM) Earnings Call Transcript & Summary

Good morning, everyone. I'm Nikhil Jain, a part of the specialist solution engineering team at Salesforce. And I welcome you all to the webinar of Salesforce Sheild wherein I will identify how Salesforce Shield can help you out with building up a more robust data security framework. Right? So let's get started into it very quickly. So just a [indiscernible] statement before we begin with today's seminar. So Salesforce is a publicly traded company. So please make all of your [indiscernible] decision based on currently available products only. Now when we talk about data security, building that data security framework, so there are a lot of threats from which we want to mitigate, right? So today, in today's time, companies are facing threats from numerous facets. Now be it external threats wherein some hacker is trying to access our data or maybe some internal threats rising out of the bring your own device concept, there are numerous threats, which are existent across the entire ecosystem. Now adding more to the complexity, we do have compliances. Now any compliance rules or any industry regulations which come up, add more complexity to these rising threats. Whereas on one side, you need to deal with the external and the internal threats. Adding to it, you need to also make sure that your framework is robust enough to meet and adder to all of these regulations. And all of that compliance, which is coming up. Now if at all, we are unable to meet any of these compliances or there are any threats which breach our data security evolves. So that is where we end up losing out upon the customer trust. Now trust is something which Salesforce has been -- Salesforce has had trust as our #1 value across the last 20 years. And that's where we do understand the importance of trust, and we do realize that trust is the currency using which the business moves forward, right? Now getting inspired from this currency of trust, we have built out a shared responsibility model, wherein we do understand that if there is trust, that's where the business will move forward. And to build a trust, you need to safeguard and have those proactive data strategies in place. And as a part of the shared responsibility model, we, as a Salesforce responsibility, we do own of the responsibility to provide you the right set of solutions to build up that proactive data model or the data security, which is required. And at the same time, it is your responsibility or our customers' responsibility to make sure that you are able to consume all of those right security solutions at the same time, understand what is the compliance need, what is the business requirements at your end and then consume those solutions and make that security framework more robust. And that's where getting inspired with this entire shared responsibility model and the need of hour of the security, we came up with this entire 3-step framework of the security offerings, which we have or the solutions, which is spread across this 3-step framework which is on the lines of understanding what is the data about in our system, protecting the data and then monitoring any kind of protection measures which you have taken. Now this entire 3-step framework is iterative in nature because it never stops, right? And we do have solutions which can help you to build any kind of capability, which are looking at from a security framework point of view. No matter where or which stage are you in while building your security strategy, we do have a right set of solutions which you can pull up and build up your security model. You may choose to use all of our products or maybe just use a subset of the products depending upon your business needs. Now focusing upon Salesforce Shield, which is the primary agenda for today's discussion. So Shield, again, is spread across the entire 3 step framework and it spreads its wings across all the 3 steps as well. So if you see, we have certain capabilities and understanding, same in protect and same monitoring. So let's deep dive into what Shield exactly is, right? So Salesforce Shield is a suite of products, which is essentially used by most of our customers to enhance the security of the Salesforce instance. Now this sits on top of the default or the native security capabilities which are there. They're out of the box within your system from day 1. And making it more robust to meet any kind of compliance needs, any kinds of regulatory requirements or understand or monitor the user access, a sensitive data, which is being accessed. Or maybe in general just wanting to level up your sales for security. So that's why Salesforce Shield really comes up and it plays a very, very critical role in enhancing the security and it plays a very major role in terms of building our data security framework as well. So when we talk about Salesforce Shield, it primarily has 4 pillars to it. Wherein Shield is a multi -- as I said, it's a suite of product, so it switches had between multiple offerings, multiple capabilities, wherein the first one being event monitoring. At a high level, event monitoring helps you to gain access into detailed performance, security and usage data for your Salesforce apps in order to understand or monitor any kind of business-critical data, which is being accessed, understand the user adoption across our apps and then draw or mitigate risk or mitigate any kind of data prevention -- data loss prevention, which can really happen. Second one being field audit trail. So field audit rail is primarily to capture all the audit trails of the data changes and store it for future [indiscernible] or any compliance needs. Platform inception is something which is required to natively encrypt your most sensitive data, while retaining all of those critical app functionalities like search, workflows, validation rules, all of that is remaining intact while encrypting the data. And Data Detect, which is the newest member in our Shield family, it helps you to identify any kind of sensitive information, which may be lying somewhere else in your or apart from the designated places, right? So there would be certain designated fields wherein the sensitive data has to lie. But for some reason, it is lying in some other fields. So that's where you can understand where the data is really lying and you can take measures to see care. So now let's do a deep dive into what even monitoring is. So as I said earlier, even monitoring helps you to gain detailed performance level insights, security insights and usage data as well. So it helps you to analyze the user behavior to drive adoption and training of your Salesforce apps which are building up and also drive the ROI in terms of focusing where the investment has to be put in, right, in terms of the usage, adoption and performance bottlenecks, which might be rising. Secondly, what you can do is you can also build up customized flexible security policies. Now these policies gives you the capability to identify and prevent malicious activities in real time. And lastly, even motoring also plays a role of performance monitoring tool as well. So what specifically for Salesforce wherein you can monitor the application performance. and use those insights to improve the user experience. Now our key use cases where an event monitoring is very useful. Primarily, it is for the, use case #1 is the user and application visibility. Now as we are able to get those user level, user behavior data, we are able to identify what the user is really doing, and we can also track their logic sessions or page views, report downloads and much more, right? Now this data not only helps us to just do a user level monitoring, but also helps us to capture the data, log those events from a compliance point of view as well. So if we were to see that, okay, what user is spending what amount of time of particular page or what is the top most pages being utilized, all of those kinds of visibility or something which can be gained. Second one, data loss prevention. So now, as I said, there are certain IT policies which you can create, right? So using a combination of the monitoring tools and IT policies, which you can create in real time, you can go ahead and mitigate any kind of data losses, which can be potentially happening via -- we put downloads, data exports, list views, APIs and multiple other leakage points. So that is where you can have those customized policies being built up and make sure that the data which is being exported out, can be safeguarded. Now this is key from a PII data and a privacy point of view because all the regulations which are eventually coming up and considering the Indian scenarios, there are new laws, privacy laws also coming up, data protection bills coming up. So that's where data loss and maintaining the privacy of the PI data becomes a key factor. And that's why these policies play a very, very major role. Then the third piece is on the lines of production and adoption. So that is where, as we are identifying the use of [indiscernible] data we can also identify what is the pattern in which they are utilizing our Salesforce app. Now once we have those patterns, we can identify at okay, are the users really using the Salesforce apps in the right way. Are they using it the way they're intended to? And also, you can identify that, okay, these are my top usage patterns, and this is a place where I need to focus more my investment upon and improve the things which are required. Right, in terms of removing the bottlenecks. And lastly, as I said, it is on the line the performance monitoring. So any kind of page views, APIs, Apex, report downloads, report views all of those data is something which can be captured and it can be insight and you can get granular level insights and focus in terms of optimizing the user experience. Now those were just the use cases, right? Now if I were to talk about the technical side in terms of what are the key features of event monitoring. So that's where the first one is even log file. So event log is the core of event monitoring, wherein we capture all of the event logs and store it within the system, right? This is a place where you can access these event logs on demand, you can draw insights, you can draw dashboards or you can connect it to any kind of SIEM tools because this is API enabled as well. Second key feature is on the lines of real-time event monitoring. Now this is the place wherein you can get near real-time insights of the user activity. We use as logged in or page views being page is being viewed or report is getting viewed. So you can get near real-time insights and you can take real-time actions to mitigate those risks or fix those potential threats which are coming up. Now with event monitoring, you also get a built-in module, which is threat detection. This is a statistical MI -- ML-based detection module, which can help you to get key alerts from a threat detection point of view. Of course, I do a deep dive into it eventually. The fourth one is on the lines of policies, which I was talking a lot about in the previous Slide, where you can create those flexible customized policies in order to mitigate those data losses and the data leakages. And lastly, you can also get a prebuilt dashboard as a part of even wanting to analyze these logs. I'll just take a couple of minutes to be dive into each of these capabilities so that we have a better understanding about what even monetary offers and what are the features of it. So event log files, right? So this is a piece where you have the entire dump of all the logs, which are getting captured. This is primarily the database or the storage wherein all the event logs are getting stored. This is a piece which will empower all of your insights to view any kind of dashboards to access these data elsewhere or by the EPAs. Now these are the tool -- or these are the files which will eventually empower the dashboards or the prebuild dashboard which come up with even monitoring as well. Now real-time event monitoring. So this is something which is using the native capability of our event-based architecture under the hood, which is platform events within Salesforce. Now as soon as an event occurs, we capture that event, log it and also push it as a platform event. So what you can do is you can subscribe to these event logs in near real time and have a live dashboard in terms of monitoring what is really happening. Now the benefit over here is what you can do is, since you're getting in real time the insights, you can also take dump of it elsewhere and also take measures in order to protect the data and mitigate that in real time if required. Threat Detection. Now threat detection, as I said, there is a statistical ML-based module, which gives you those alerts. So events or threats like [indiscernible] stuffing. API normally, report anomalies, session, hijacking. So all of these alerts or potential threats are being detected based as the use of behaviors, and it gives you those proactive alerts. Now what you can do is you can send out feedbacks to the system in order to say that, okay, this was actually an alert and not a false alert. And also -- but as a next step you can do if you have got a [indiscernible] a lot for a specific set of user, maybe you can prompt the user saying that, you know what, there is a [indiscernible] stuffing attack on your credentials. Maybe you want to this reset your password or make it more stronger. So that is the kind of alerts which you can go on and take forward, right. Similarly, there are alerts on the lines of report anomaly and EP normally. So in case if there are certain abnormal user behaviors wherein effort, typically a user creates a report for around 100 to 200 rows of data and all of a sudden, the user creates 1,000 rows of data. So it is deducted as an anomaly event and you get a log for that. So again, all of these things come under threat detection, you get proactive alerts and you can take proactive actions depending upon the alerts we see. Transaction security policies. Now this is, again, a key, key thing from a data protection point of view. This is a piece which will eventually help you to mitigate any kind of data losses which we are looking at. Typically, when we understand the data leakages, it is primarily wherein the data is available from a consolidated view, right? Now in Salesforce, when we talk about data being available in a consolidated format, it is primarily in list views or reports or APIs, right? So you can go ahead and create report or create policies on the lines of certain scenarios. A classic scenario is you want to limit the report based on the number of data. So for example, my users can go and create report, but they cannot create reports if the number of records in the report is more than 500. Or maybe you want to restrict certain fields from flowing into reports. Maybe you don't want any PII data to be a part of the report? Or maybe you don't want a group of users to create reports on PII data, but other users can go and create reports on the PII data. Whatever the use case is, you can go over and create those policies in this particular module. And once the policy is created and activated, any kind of user action which is being performed and the event is marked to a policy, we match it against the criteria which we have defined and taken the subsequent actions. You can either choose to block the action, you can notify the admin or you can trigger a multifactor authentication as well. So that's where you can create separate policies for separate departments as well, depending upon your needs. And you can have a user-level policy or check-level policy, field-level policy. So that's how flexible it is. You can go to Apex route or user low [indiscernible] builders as well. And lastly, even monitoring analytics app. So as we were talking about all of these logs getting captured and the event log files, wherein the data of the logs are getting dumped. This is a place wherein you can visualize these logs. So one is a raw dump. And now from the raw dump, you are the graphs or the visual patterns which you can identify. So along with event monitoring you get certain licenses of CRM analytics as a part of the bundled offering. So using that, you can build -- you have 16 prebuilt dashboards using which you can visualize these logs. Right? So if I want to identify what has been the log-in trend for a specific user or the page use for a specific page. So how many times is a particular page viewed on a particular day, broken down by the user, by the profile, by the role. All of that is possible and you can pick it up. So that is where these analytics app is, again, point and click, just few clicks and you can configure these apps. Because these dashboards are prebuild in nature. So that's where your logs will eventually come to life with this particular analytics app. So this was a very brief overview about event monitoring wherein it helps you to summarize it helps you to monitor what the users are up to, attaching the performance data toward where and it switches the hard to become application performance monitoring tool exclusively for Salesforce. Adding to it, it also helps you to prevent any kind of data leakages, which can potentially really happen. And then added benefit is on the threat detection module. In case if there are any credential stuffing such an hijacking or any anomaly events which can arise. So that is where even more plays a very critical role and being the first leg of the Shield umbrella. Now there are key resources, some [indiscernible] modules some health articles and some implementation guides, which are there. So all of these links, I have put it together in a combined PDF, which is attached to the resources tab. You can download that PDF and access all of these resources as and when required. Now moving on to the second leg of Shield which is field audit trail. So now field audit trail, as the name says, it is primarily to maintain audit trails at a field level. So it primarily helps you to capture any kind of data changes within your Salesforce instance and have auditor for it. Example of it is, if any of a user goes ahead and updates the contact number on contact record, right? So I will have audit trail with sales. This was a user who updated the phone number field at this particular point of time. This was an old value and this is a new value. So that is exactly what field audit trail does. You -- most of you might be similar to field history tracking, which is already existing in Salesforce. It is an enhancement over top of it, where in field issue tracking essentially helps you out with somewhere around 20 fields per object with an audit trail retention period of 18 months. But field audit trail enhances the up to 60 fields, which is again extendable up to 100 fields when required, and the retention period is also waived off. So essentially, the data and the audit trail remains with you for an indefinite period of time, month in the time you delete it. So that is exactly where in field audit trail helps you out and what -- the key [indiscernible] of field audit trail. Now key areas where in field audit trail is helpful primarily, again, from a compliance point of view, there are requirements to keep the auditability and audit trails of the data changes which have been happening. So having those audit checks and inspections in place, that is where field audit trail is point number one, helpful. Second one is, at times, there are some incorrect data updates, right? So in case if you want to do a very, very minute record level data recovery from an update which was not meant to be. So auditors can give you a view that, okay. The most recent change on this particular field was at this particular point of time, and this is the old value. So in case if you want to roll back, you have the new value and the previous value as well. So the recovery and the rollbacks become easier. Retention, again, it goes hand in hand along with the forensic level requirements and the regulatory ask as well. At times, the audit, trains are to be required to be stored for 5 years. 7 years or 11 years, depending upon the industries. So that's where the retention period is waved off, so you can essentially store these audit trails for the amount of time you want to or until the time you're delete it. And as I called out, it has enhanced the files retracking limits. So you can essentially store the -- capture the history tracking or audit trails up to 100 feels extending from the existing 20 fields, is by default. So this is what field audit trail is. This is how it helps you out. I'm not pausing for now for the Q&A. There are my colleagues, [indiscernible] and [indiscernible], who are on the Q&A channel trying to answer all of the questions. I'll eventually take all of the questions in the end once I'm done with the Slides, and that's where we'll pick up any unanswered Q&A if there right? So coming back to the field audit trail. So we did understand field audit trail, the second pillar of Shield is primarily to play around with the auditability capabilities and the regulatory tasks. Regarding the field audit resources, there are certain resources which are available, which I have tagged on a particular Slide, which is again there as a part of the Resources PDF, which is attached. You can refer to that PDF when required, and you can learn more about your field audit trail. Just a quick check. Am I audible there was a bit glitch in the network. So yes, so sorry for that glitch. Just some power supply issues. Yes. So platform encryption, right? Platform encryption is a third pillar within the Shield umbrella. Now platform encryption is primarily to deal with any kind of encryption requirements or any kind of compliance, which is required to going to all of the detectors. Now this is a capacity which primarily works behind the scenes at a database level, wherein you want to make sure that any of your data, which is being stored in any of the files, search indexes and any kind of data wherever it is residing in the Salesforce has to be [indiscernible] you may chose to encrypt all of your data or just a subset of the data, which is PI sensitive with your own set of teams as well, right? So that is why platform encryption is something which helps you to safeguard and encrypt all of it behind the scenes at [indiscernible] data base level. Now key use cases wherein platform encryption is useful. First one primarily, we do understand at times customers have this sense of insecurity wherein they say that, I am storing all of my business critical data within Salesforce and it is our database, which is owned by Salesforce and not by the organization or by the company itself, right? That's where -- while we do have certain capabilities in place wherein we do make sure that your data is always safeguarded within our databases, but in case you want to take it a level higher and want to make sure that you want to enter your data with your own set of teams, more like a bring your own key concept, right? So if you want to manage the entire key management life cycle. So that's where platform encryption has that particular use case, you can bring your own set of keys and encrypt the data. At the same time, making sure that we are in encrypting the data and meeting up to your expectations, you are also up to speed with a sense of security that okay. even though my data is being stored within Salesforce, it is encrypted with my set of keys. It is not accessible, and I can go ahead and expand up my business, add more data as a required. And third one is more on the lines of a compliance requirements, right? Something on the lines of [indiscernible], PCI, again, it is more like an industry-driven compliance regulations if required. But that is a piece wherein you can go ahead and encrypt your data as it been required and make sure that we are compliant with the industry regulations to acquire. Now how does platform encryption really work, right? So first one, it is it uses the encryption capacities. So by default, you supply is the key. We will be using an inclusion algorithm, which is a little higher than the standard encryption which we use. And adding to it, you can go and create encryption policies. These encryption policies are helpful in order to identify which fields do you want to encrypt and what are the rules of the policies, the files and attachment, which really you want to put and enter the form. And what would be the encryption algorithm which you really want to use or of encryption approach, may be a deterministic approach or a [indiscernible] approach. So the first step is you define the policies once the policies are defined and activated, that's where the encryption logic comes in. Now what would be the encryption logic, it would be primarily on the lines of keys which is supply. Now you may choose to tell Salesforce that Salesforce, you may derive a particular key or you can supply in your own set of keys in order to encrypt the data with your own keys. As a part of road map, we are tying up with AWS Key management as well. So you can upload your own set of keys in AWS and you can utilize it within platform infection. Now just a quick heads up, while the name says platform encryption, the entire encryption capability sits behind the scenes in a database, it is not at a UI level. It is purely at a database level encryption which we're talking about from a platform encryption capability point of view. Now by default, just a quick view of what is the encryption capabilities, what we have. So out of the box, you get a volume level encryption, wherein we do our database level or storage level encryption, which is available in both first-party data centers as well as [indiscernible]. That is something which we give out of the box. But if you want to make sure that your search indexes and your app data or any kind of custom fields or any kind of files and attachments, all of that should be encrypted. So that's where platform encryption kicks in. And again, both on the first-party data centers as well as on [indiscernible]. platform encryption would be utilized to encrypt all of these data [indiscernible]. One key thing to note is platform encryption is native to Salesforce, right? So any encryption, which is happening is within the Salesforce platform and any kind of automation, right? Any kind of workflows, any kind of validation rules, any kind of queries which you have written, most of it don't break, right? So you can attain a higher level of security and drift your data while making sure that your customization business workforce are intact. So that is a place where native encryption capacities become very, very helpful. Without disrupting your business, you can enhance the security as well. So that is what our platform encryption is. Again, there are certain set of resources which are available on Trailhead. There are certain white papers, technical with papers to understand more about under the hood encryption logics, all of that. It is all attached in this particular Slide, again, a part of the resources PDF, which is there. Please feel free to download it and learn more about the platform encryption capability. Now moving on to the last leg of the Salesforce Shield umbrella and the newest number within the portfolio, which is called Data Detect. Now Data Detect is something which was added recently. And as the name says, it is somewhere around detecting the data within the Salesforce system, right? So typically, whenever we design our Salesforce odds, we do define certain set of deals at an optic side. Now the reason we define deals is to give a designated space to [indiscernible] certain data. And then we take it a level higher wherein we flag out those particular fields and classify it as HIPAA, PCI and other sensitivity levels. Now at times what happens is we have various different kinds of users, right? Now we may say that, okay, this is a field where you want to score phone number and e-mail addresses and you classify it as PII. Over a period of time, your users end up storing data within some other fields as well. Something like the notes being on a long fixed area, text area fields. So what happens is the sensitive data, while you have designated spaces and flagged off areas, but your sensitive data is also residing elsewhere and some external fields where they are not meant to be, right? So that's where Data Detect helps you to identify and classify soon data, which is being started across ore and it uses patent matching and certain algorithms to identify those data and help you flag it off and classify. And that is where she'll -- Data Detect becomes really, really helpful. Key areas wherein it is -- it has major use cases is primarily getting our understanding of the Salesforce landscape, the data, where in the -- where is your sensitive data getting hidden? Are there any places where they are not intended to be, but they are still residing, right? That is something which you get an understanding about. Now since your sensitive data is not in the designated spaces, are you still compliant? Are there any governance rules which might be breaching, right? Or do you need to classify or reclassify [indiscernible] That is something which can be one of the key use cases over here. And lastly, since you're getting compliant, you can have more increased control, identify where the fields are in classifying the data at a more granular level. Typically, it all starts off with what do you want to detect, right? So you can choose to detect email addresses, credit cards, SSN, URLs, IP addresses. Or going forward, you can also given your own custom patterns in order to detect the sensitive data as a part of the [indiscernible]. Once the you detect -- you stay that okay, detect this particular pattern, the algorithm runs it scans the data across the entire or whatever data you are residing, whatever data you are building up in the Salesforce instance. It tries to flag of all of the data [indiscernible] of flags with the sensitivity levels and tell you what is the data which is there, what it should be classified as and which other things where it is being stored up. And the next step would be wherein you can go ahead and take level actions on top of that data. right? So you want to say -- you want to classify the data, you want to reclassify the data or you may want to take any subsequent actions, instruct the users, in particular certain ways. All of that is possible. So that is where Data Detect is really helpful if in terms of identifying, addressing flagging the data and then reclassifying it. So that is how Data Detect plays a very, very critical role in terms of maintaining the privacy of the data. So with that, -- we have talked about the 4 key pillars of shield the 4 key aspects. Just to summarize, event monitoring, as we talked about monitoring capabilities, data loss prevention and performance monitoring. Field audit trail is on the lines of data auditability and retaining the audit trails. Platform encryption is primarily on the lines of encrypting your data at rest with your own set of keys and while maintaining the app level functionality and the capabilities. And Data Detect to maintain all of the data sensitivity, data privacy in order to identify where is a [indiscernible] elsewhere in the ore, right? Now as a whole, Salesforce Shield is a particular offering, which helps you to address multiple aspects of your security framework, when you talk about data privacy, access to the sensitive data, data loss or monitoring the user activity, potent cyclical insights, auditability. There are multiple tick marks which Shield really does from a compliance and regulation standpoint. And that's where it essentially plays a very, very critical part of your entire security framework, which you intend to pay for. And again, there are multiple resources, which we have listed down upon in the slide deck in the resources PDF as well. There are dedicated railhead modules. There are dedicated white papers and websites, which you can refer. And there are short demo crisp videos as well available on the -- our trailer modules itself, which you can learn more about Salesforce Shield and there is a dedicated learning only map as well, where you can more about Salesforce Shield. Understand how does it play? Where can you leverage? What are the use cases you can play around with and what -- where can it fit into the organization? So with that, I'll just take a pause, I'll come back to the Q&A side and look at any questions which are unanswered, and I'll just take them up if there are any questions. Just a moment so I can [indiscernible] Q&A tab.

Okay, where do we have the access to the materials? There would be a resource tab on your console, which you're accessing the webinar you're accessing. In the resources, you would be seeing one PDF file which is a compilation of every resources, which I've mentioned in the Slides. Field audit trail, can we track on record levels? Field audit trail is at a record level. So it works at a record level at a [indiscernible] level in terms of giving you the insights of what changes that happened at a particular field. You can choose up to 100 fields on which you want to enable field audit trail up. So transaction security policies are something which act in real time. So at all you're talking about a scenario wherein we want to block certain users to download a report or access or report with more than 500 rows of data. This is something which happens in real time. So if your report is having more than 500 rows of data, and the policy says it has to be less than 500, there would be a block message, which will show up and the user will not be able to access that report. Now this policy is applicable on existing reports as well as well as the new report, which would be eventually to be built up. So in regards to real-time event monitoring, is there any kind of additional configuration required to enable it? So to enable real-time even monitoring, there is just one button which you need to just enable. But in order to consume the real-time events, you need to have a subscriber who listens to all of these event screens in real time. and pushes up on to a particular dashboard in order to visualize it, right? So that is the part where in order to consume the real-time events is a piece where you will have to do some customization of some configurations to consume. Can we build reports on field history, right? So field history is something which we are storing. We are storing the audit trails and it has been stored within our Salesforce instance. You can build reports using any report builders or using an BI tools. Because the data is available within the sales force ecosystem, you can consume it. But again, those reports are not available by the fall, you can build it on your own using any type of custom building approach. Field history tracking, does it impact the performance? Yes, too. So the answer is a bit, I would say, not straightforward. It will impact the performance in a certain way. So that's where we have a limit on the number of fields on which you can implement field audit trail. So primarily performance is the reason that's why we have limited it up to 60 or 100 fields. As a first level, you will get up to 60 fields on which you can enable field audit trail. If you want to enhance it, that's where we internally check what is the use case. Why do we want to enhance it beyond 60, and then we allow you to go up 100. Now beyond 100 again, a performance trade-off, we would recommend you to just enable field history, tracking or field audit trail only on the [indiscernible] and not on the entire database. So because, of course, there would be certain trade-offs because every transaction would be then creating audit trails right? So the recommended approach over here is to keep the field listed tracking enable only on the most important case is critical to you. And which might draw or pull you into any kind of compliance or regulation aspects. Okay. Are there data classification template industry-wide available? So as of now, for data detect, there are data classification templates, which are not really industry-specific. While, of course, you can engage with the account teams and the solution architects in Salesforce who can help you guide from an industry point of view, based on our experiences with similar customers to yours within the industry, we can help you guide in terms of the best practices, what we have been doing? And what are the key data, what has to be protected. Suppose I have enabled shield for a field with 100% encryption later I disable the encryption, will 100% data be encrypted and stored without encryption within the Salesforce database So typically, when you enable incretion, it will encrypt the data and store it within the database with the encrypted values. So that's why the entire encryption logic will kick in [indiscernible] Now if you were to say, disable platform encryption going forward in any time in future, of course, we'll have to decrypt the data and store it back within the Salesforce because that's where you are disabling encryption. So you we would no longer have the keys using which you had encrypted the data. Also, we would no longer will have that enhanced level of encryption algorithm using which we have to encrypt the data. So yes, when you enable it, the data will be encrypted, once you disable it, the data will be decrypted and store it back within the database. But again, there would be an entire encryption decryption logic, which will be kicked in there would be some time using for which the entire process will take some time to execute and [indiscernible] Shield can detect the development and code level changes? So no shield is primarily to deal with any kind of user level changes, which is happening. So even monitoring primarily works on any kind of user activities which are happening. So any kind of change these accesses or any kind of apex accesses, Apex execution, EP execution, all of that can be covered using shield. Again, field audit trail is at a user level in terms of the records, which are getting changed. Platform encryption is more a behind the scenes. Now if you were to talk about any kind of code level changes or development, you can look at different offerings more like a DevOp center, which can be helpful in order to identify kind of meta data changes, which have been done in kind of sandboxes is there. Does event wondering help derive the report usage in the application like when the report when is the reported or dashboard used, can we derive the reported dashboard? Yes. So event monitoring will give you a view in terms of how the report is being executed, which are the top reports which are being executed by the users, any report which are getting downloaded, or what are the typical number of rows, which are a part of our particular report. This is available in both real-time events as well and also in the dashboard. So if we were to analyze which are the top reports being consumed within your Salesforce, you can use event monitoring for that. Is even monitoring a paid package? Yes, event monitoring would be a paid package. How would it get implied on your specific Salesforce? Or is something which can be taken up with your account team in order to identify what would be the commercials and what would be future conversations around it. But Shield sits on top of your existing [indiscernible] it is more like a turn-on feature, which you can enable and consume it as and will require an enabling on your business needs. So thus the Shield abide by the [indiscernible] clauses? So to answer your question, Shield does abide by privacy requirements, certain rules which are required from a [indiscernible] aspect from a data previously. We might not be doing a direct correlation or direct mapping, which can be subsequently in a one-on-one conversation depending upon your business needs, our priorities and the business challenges you're facing from a compliance point of view. But yes, it will does support your strategy to get compliant from aspect as well. Primarily around monitoring [indiscernible] auditability, infusion of data privacy of the data, all of that is getting covered from a certain aspect. What is the retention period of for the event logs? So in event monitoring the event logs are getting retained for last 1 month. So we do store those logs for a holding period of last 1 month, whereas real-time events are stored for last 6 months, but you can choose to export these loans out of Salesforce and store it elsewhere for a longer retention period. So let me see if there are any more unanswered questions. So I don't see a lot of unanswered questions. Most of them have been answered. Thanks, [indiscernible] and [indiscernible] for handing the Q&A. So after enabling Shield in production, does it have any impact on any apps which are running? Shield will essentially not impact any kind of business capabilities, which are being configured within your Salesforce, any kind of custom maps which are built on top of Salesforce, they remain unimpacted. It will essentially just help you enhance the security and the policies which you create, it will help you to adhere to those policies and generate those alerts as and when required. So it will not break any kind of business functionalities which you have created. I think there are no more questions specifically. I see a lot of questions coming up for specifically around the commercials around Shield. So that is something which you can reach out to your respective account team or account executives for Salesforce and they can help you guide with what would be the commercial specifically for Shield, right. So yes, I think there are no more questions. So we'll just close out for the day. Thank you so much for your time. I hope we made good use of your time in terms of giving you a [indiscernible] understanding about what Salesforce Shield is, how does it help you? Or how does it play a critical role in being a part of your data on a security framework, which you are eventually building upon. Please feel free to reach out to your Salesforce account teams for more information on Shield. Reach out to your Salesforce account executives to get a more one-on-one insight about how Shield can be helpful to your organization with respect to our industry and specifically for commercials do reach out to your specific account specialist. Thank you so much for your time. Thank you. Have a good day.