The hidden dangers of sensitive data: Navigating compliance risks in SAP SuccessFactors

Hi, everyone. Welcome to our session today. My name is Sarah Enders. I'm on the marketing team here at EPI-USE Labs, and we're so excited you could join us today. Today, our webinar is the hidden dangers of sensitive data, navigating compliance risks and SAP SuccessFactors. We are recording the session today, so we'll make that available to you as soon as we can. And, I'd like to introduce today's speaker, James Watson. James Watson is with EPI-USE Labs. He leads our global data privacy, practice, and he brings more than twenty years of experience helping SAP teams tackle complex data management and compliance challenges. So we will take questions, but we'll wait till the end of the session to answer them, but you're welcome to put them in the question box on the GoToWebinar control panel as we go along. So I will turn it over to you, James. Perfect. Thank you, Sarah. And, yes, good afternoon, everyone. As mentioned, I'm James Watson. So as well as being director of global services, I also act as the product manager for our data privacy solutions here, which includes integrated SuccessFactors processes. So I've been asked to talk with you today around some of the learnings we've had with the software offerings. I'm gonna do a short demonstration within our live demo instance to be able to show how the different types of privacy compliance can help to be managed through the EPI-USE Labs software. And, hopefully, we'll have some time to discuss a couple of use cases and where we've seen this going as we're going along. I don't think we'll be taking quite a full hour of your time as was booked in the original invite. I'm hoping for somewhere around forty, forty five minutes including some questions, but we do have the extra time if we have a lot of interest in answering items. Okay. So to start off with why we're talking about privacy. Privacy, obviously, the popular thing that everybody's heard of has been GDPR coming into effect in two thousand and eighteen, but it's a lot larger than that now. We're up to around about ten individual state laws over in America. The LGPD in Brazil came out around the same time as GDPR. But, also, as we go around the globe, we're seeing far more data items being brought in data privacy items being brought in the different countries. This particular sort of presentation was made a couple of years ago, and it's already out of date by an additional thirteen privacy laws that we're currently in the process of updating to bring this through. So it is a very hot topic that our companies are having to deal with. And because of the way these laws are being written, even if you're not in that country, you're still eligible for the processing of data of the citizens of those countries, and therefore, we'll have to adhere. So I do always use GDPR as the example for this purely because it's had the most enforcements put against it. But it may surprise you to know that the highest volume of enforcements for the European Data Protection Act have been in America, and they've been against Meta and Google and companies like that. I the Meta is the largest overall fine, which is now standing at one point three billion dollars, that they were far fined for various misuse of data processes. But along with the sort of diversity of all of the different laws, there's also a collection of absolute core principles that they're all introducing. And we, as a technology provider, we can't answer every single demand that's in there because the this will deal with things like your contractual arrangements with third parties, how they're handling your data, your data your sorry. Your paper management processes within your work centers and different areas. The it's not always going to be a technical solution, but there are some very specific areas that we find are common between the laws that we're able to help you out with, and that's where we're gonna focus in today. So to start off with, we'll think about the informed and explicit consent for the use of data. This is true between all of the laws that occur around the world, And it brings in the principle of being able to say that you must have the informed and explicit consent for the different uses that you're using that data for. So to bring that into sort of a real life scenario, your employee, you have the informed explicit consent in the employment contract to be able to hold their information for payroll processing and for contractual terms between you and the employee. However, you or most clients have not put in explicit consent to use that data for testing. So as soon as you move that from a production environment, SuccessFactors, ECP, PCE, on prem HCM, s four, h four, whatever combination of data you have. Once it's copied to the nonproduction system, you're actually no longer sitting under the informed consent to be able to use the data now for testing. To be able to protect against this, SAP have also included in their data processing agreement. It's section two point one point three, if anybody's particularly interested, that it states the production data should not be used outside of production. So you have a couple of drivers to be able to say. You need to be able to have production processes working efficiently, which means that changes HR service packs, etcetera, need to be tested, but then you can't use the data from production for testing to be able to get into the scenarios. So you then have an issue there that needs to be addressed, and that's one of the areas that EPI's Labs can help. Similarly, we saw a large increase over in Europe with the advent of GDPR in the requests for a subject access request or a DSAR. And the DSAR process is to be able to say, I would need to find all of the information I hold for a particular employee, customer, or vendor, but a citizen of the privacy law in question. And then I need to be able to disclose it within a formatted PDF that can be utilized for the client to consume. So you have these rights to access that need to be addressed. And then finally, you have the idea of retention periods and removal with the onus being put on each company to be able to confirm in their legal compliance statement, the reason, the justification for holding that piece of information. And if you can't justify it, you would therefore need to remove it from, the productive environment and any test system copies. So there's some fairly large challenges tied in with everything that's wrapped around that. And as such, EPI's loves to boil it down to this road to compliance for the different pillars that every business needs to go through as it's considering what it's going to do. So the first thing is to obviously identify your risk assessments. So identify the where the personal data is stored and do your risk assessments over who can access it, what processes are running against it, and what controls do you already have in place. Many companies are already engaged with auditors and already have processes that are starting to look at this. Or you have a data privacy impact assessment is another common phrase that we hear in the industry, the DPIA. But from a technical point of view, where EPI's Labs can help is in finding and mapping the personal data within your SAP ABAP systems, but also through SuccessFactors, and also reviewing who can access that data. So your access risk and control framework, whether that's been done through GRC, through standard roles authorizations for SuccessFactors, what your role based permissions, matrix, and management, and how that's been processed through. We've got software items to be able to support in the analysis phase of actually what is the privacy business problem and therefore the business case for the solutions that will then come forward. And then we always talk with our clients about cleaning up the backlog in production. So where you have to introduce retention criteria and let's say you've been running a productive system for twenty years, and your longest legal justification is often the taxman in the case of employee data. The on the taxation laws, they can come back and query you up to seven to ten years depending on the country. I haven't been aware of any longer retention periods past ten years due to taxation. But in that system with twenty years worth of history, that means that you've got at least ten years of history that you shouldn't have anymore. And if the employee no longer works for you, you have no legal justification for that. So you need to have an initial cleanup of data to be able to get rid of what you don't need. Now the products and services we're gonna talk about today can be executed within the framework of a productive cutover with plenty of time and backups and processes to ensure that we have effective processing of that data removal in production. We then see our clients to talking about the test systems, so data anonymization. Now there's lots of different words that get used around this, and I want to be quite clear over what it is that we do. We have the data masking, which is often referred to in the data masking processes that would often get referred to as UI masking. The where the data still exists in the database, but it hasn't actually been removed from the system itself. Now we don't feel that meets the tone of the privacy laws, and therefore, we focus rather on data scrambling, replacing the data in the database and no longer having it recognizable either internally or externally. So although where the terms often get mixed up to a technical legal definition, our approach is actually pseudonymization because we will replace with a realistic looking data rather than just scrambled information where things are jumbled up. So the UI masking is not something that we provide. SAP has standard solutions around that. But the data anonymization or scrambling or pseudonymization, those words are all interchangeable. And where you've got these sensitive copies of data outside of your productive servers, then you can use data scrambling to be able to address those directly. Then we look at the subject access requests and the ability to remove individuals, and that's gonna be the demonstration that I I show you today that for a combined SAP HR and a SuccessFactors instance, being able to identify the information we hold on them and then processing that for removal from the from both databases consistently as a single process and how that would be managed by your business. You then also have the idea of proactive data proactive identification of data for removal. Now in those cases, the what we're talking about is retention period. Being able to automatically identify all of the employees from your environment that should be removed, submitting them into a business process, and then handing that out to the business to approve and process the data removal. So the key thing in that messaging is to be able to understand that we are talking about a business owned process, That the it's often a difficult situation because the business will own the data, but IT are owning the infrastructure. But what we are talking about here is a business driven process for data removal that is driven by legal and compliance needs, not technical data reductions. But the business team can't do that without the support of technical teams to be able to process it within IT. And we've built all of these solutions with that in mind that the business decisions over what, how, and if data would be removed into policies. And those policies are available in product, and the product can be executed by the business even though it's been transported, tested, and delivered through the IT teams. So everything has been built with that conflict in mind to be able to bring it through. The final thing on this sort of journey to compliance is then obviously ongoing audit and review. This is never going to be a onetime project and process. You're always gonna have to consider this into that circle of development moving forward into your change approval board processes, cap meetings, whatever it is you may call them in your individual organization. You're gonna have the same needs to be able to say, we're adding customizations. We're buying third party solutions. We're changing the data model. Therefore, we need to change the processes that are controlling our compliance with the privacy laws within that data model. So you are gonna have to change your business processes to be able to put security as a central process or privacy and security as a central process as you move forward and how you manage that. Okay. So let's talk about a specific scenario. Now many organizations are running SAP for employees for payroll. Let's say that this employee goes and works on a particular project, and in that project, they incur some travel expenses. So they now need to get processed under project finance for the expense payments. So to be able to technically do that in SAP, that employee has their data replicated to a vendor record, And that vendor record will have all of the informations and linkage through to finance projects and payments that have been made into that process, which also takes certain informations depending on the configuration into, the text descriptions, into the transactional data of which bank details were used for payments, etcetera. So your employee data is all replicated again into the vendors and put into transactions there. Depending on your industry, that vendor can also be a business partner and or a customer. So depending on where they're processing their data, if they're using SRM, CRM, they are, by definition, a business partner to be able to transact within those systems, or you could be in an industry where that employee could also act as a customer within your environment. And if you are going to process any of these privacy individual rights of that right to access, the right to removal or deletion or the nonuse of data outside of the consent that's been given, you need to make sure that you're treating that whole data subject, that whole individual person as a single record, which then, of course, means that the data is split all over the tables around multiple systems, integrating potentially to cloud and non cloud on prem solutions. And you needed a software provider and software that can actually handle those. So at EPI-USE Labs, some of you may already know of us, not maybe not everybody, but we've been working as a close SAP partner now for twenty five years, maybe a little bit longer. And we've had solutions that have been dealing with data copy, data transformation, selective data transfers to s four, the data scrambling that we've spoken about. So we developed a business object workbench of objects that contain not all of the tables and the relationships that make an object consistent, but also how they link between the systems. And then with the anonymization processes in Data Secure, we then linked down to a field level to be available to say in this brief example how a customer from ECC becomes a business partner in CRM and a zero customer info object in BW, that they're all interconnected. And if we're going to take one of our processes to either scramble, remove, or provide the data for in an access request, that we need to be able to do that consistently. And for doing that across the HR SuccessFactors is also included. We've already done the integrations to Employee Central through the user record, the per personal, per address, etcetera, and how that links back to the original employee from an SAP viewpoint. So we've then boiled the solutions down into four categories. We've got data disclose, which is for the right to access, data redact, which processes those individual cases or batch cases for data removal. We have data retain where we can proactively go and identify keys that need removal from the productive system and Data Secure, which will do the scrambling of data within the nonproduction systems. So between these four applications, you can provide yourself a strong suite, and the whole design has been built around business owned processes to directly address the privacy compliance concerns and with the knowledge and integrations that allow us to understand where all of the employee vendors, SuccessFactors users are going to exist in one place and performing the anonymization or disclosure, etcetera, against all of them. So starting with Data Secure, the first thing that we have to make clear is that we do currently still have a requirement for an ABAP stack. We are working on a direct cloud solution, but at this moment in time, we're still processing from the ABAP stack and making Odata API calls to your SuccessFactors instance to be able to find the information that needs anonymizing in both systems. We're then running a calculation process in this example, changing Stuart Taylor to James Smith, and we're going to make the same changes to the data that we've read from SuccessFactors. Now for the SAP side, that comes in and does a direct database update. We don't trigger iDocs or workflows or change documents and reintroduce changes into the system. And for SuccessFactors, we're then gonna perform an OData API call again, but this time as an upsert to the same user record, but with the anonymized data to be able to bring that into place. Now, obviously, we don't have quite the same choices in SuccessFactors as we do in SAP being installed directly to the same database and through the SAP GUI. We do have to use SAP's API that's available. But what we can do through the two calls, both the read call and the observe call, is make sure that your data is being anonymized consistently between the environments. So at this point, I'm going to just step away from the presentation, and we're going to, keep working in SuccessFactors. And we're going to search for a particular employee within this SuccessFactors instance, so Sam Chris Jones. And I've also got a linked HR system. Now in this case, we have done a direct linkage where the partner is exactly the same key. So we've got Sam Jones in both the SAP system and in SuccessFactors linked together with all of the sort of normal information that you'd expect to see for a US employee, in this case, with a Social Security, etcetera. Now within the SAP system, if I go to our data privacy desk, then we're able to have the options to be able to see about data disclose or data redact. Now data disclose is where we're gonna start, which allows us to be able to do a search based on the criteria that you've got. So your business scenario around this is you're working in the HR team. You receive a call from Sam Jones who says, I would like to have the information that you hold on me. And we're able to do a search of already indexed data to be able to improve the performance of that sort of large data search on general items. And then we present the results back within a grid of which systems data was identified in and also any duplicate records so you can choose which keys you do want to be processed and which you don't. So in this case, for example, we found three records called Sam Jones, and we would be able to confirm with the employee that we're speaking to, could you confirm the last four digits of your ID number? And they mentioned five two zero four, or they mentioned that they're living in Bryn Mawr, the phone number ending in nine six five eight, whatever it might be, then we can tell which record is the one that we're actually looking for within this process. So I can then go through and I can check all of the information that's been found, and we can also see how many occurrences of that data have been found. So that's saying that this ID number has been found in info type ninety four in the doc n one field, but there's actually been two occurrences found of that. Similarly, in the more general items like job positions and sales manager that are included in this, there are many, many occurrences of the word sales manager. So not particularly relevant as an individual identifying flag. So you could then make the decision to say, actually, I don't need that information. That's not uniquely identifiable. But all of the different data items that you see here and the things that you can search on, the things that are presented, they're all configurable within the software. Once you have chosen the right person and the right data to be extracted, you're asked to enter a password. So here, again, the business scenario would be you're asking the employee what password would they like to use. You'd enter that password, and then it's going to create a password protected PDF for me. So I'm just going to download this to my downloads folder. But, obviously, you may wish to download this to your central directory for a mail merge, for a print process, whatever's most appropriate for you. In this scenario, I'm just gonna take it through. So in my downloads, I've got a footprint report. I must enter the password before I can open the document. I also have to type the password correctly. Please excuse me. And then what I get is a password protected encrypted PDF with the business information of your business. Obviously, we wouldn't be using the EPI-USE Labs logo. We'll be using your logo. There's some introductory text that can be set by an administrator. You can also have explanation of the results. So these are notes as to why you hold that data that, again, can be set by an administrator and will then appear on every disclosure. You then get the information that's been found. In this case, you'll notice that we don't put the number of occurrences onto the PDF. That is configurable that if you chose that you did want that, then you could, But we've turned it off on our demo system. And you'll also notice that job information that I unticked in the screen has now been removed and is no longer available. We also have, an outro text page where if nothing is populated in the configuration, nothing will come out. You wouldn't have an empty blank page like this, but it's available for you to put your own terms and conditions for the disclosure that's been completed. So the search in this case has identified the information from both SuccessFactors and ECC, and has brought that through into the disclosure document. Now if I come back to our SAP screen, I also had a second option here, which is to submit for redaction. So we treat this as a segregated process that we would always expect the person that is submitting to not have the same authorization to then go and approve and therefore avoid potential fraud that you'd have the four eyed check for any data being removed, that's being submitted by an individual person, that is done through data disclose, having been able to use the search criteria and everything else. I have to pick the redaction policy that's going to be used. Now you can have multiple policies. The common example we often talk about is things like emergency contacts on your employee records. They need to be removed far sooner than the main employee because they don't have an employment contract, but they are still potentially citizens of the same country or and subject to the same privacy laws. But maybe your banking information would only be after a year, And then you're gonna have a emergency contacts policy that maybe runs two or three days after an employee contract is terminated. You're gonna have something else that runs in a year that takes care of banking and maybe some telephone or email addresses if you feel you no longer need that information. But then your final redaction and removal of data is going to be in ten years when there's no longer a tax need to remove that data. You can have multiple policies that are there, and there's also checks that can be completed at this point to confirm as it has just actually happened on some reasons to not submit that person. Now this one is rather simple to be able to say that somebody has already submitted them, and it was me. So I'm just going to remove that, reject that request. So it's removed from the queue. And then if I come back through And we'll just have to research for them again. And if you just give me one moment. So the check that was occurring there was to check whether the person was already in the queue ready for processing, which obviously they were from an earlier test before the presentation today. But we can also configure checks at that point to say that you can only submit under that policy if the withdrawn date of the employee is greater than two years or one year or whatever the rules might be that we can try and ensure that we've got the right information or the right checks to be able to say, we know the key that we're submitting, the person that we're submitting, is valid for the removal of data. So this time, this will process through, and it will confirm for me the related objects that are going to be processed. And you'll notice that we found payroll history. We've got the core employee record linked to that central person record and also the SuccessFactors integrated user. They've all been identified as objects, so we're getting a confirmation point to say, by submitting this, we will remove the information from all of these cases. Is that correct? So it gives the submitter an idea of how much related data's coming through. So that's now successfully submitted the reduction request for us because there was no other request already in there. So now, as I was mentioning, we have the ability to go in as a separate user. Now, obviously, I'm a super user in this system, but we'd have that protection in place that as a separate user, I'm now going in. I can see my cases. We can filter this view to only show the cases that I'm eligible for. I can get a little bit of information here about who it is that's been submitted, what their footprint report is, which is what you can see in the data disclose view. So you can have a little bit of information there to be able to identify who it is and from your sort of managerial point of view, make your decision to either approve or reject. So we don't give a lot of choices within Data Redact, but we review or re sorry, approve or reject the case and to be able to allow the execution. Now I'm just gonna approve this one. And, again, it shows me exactly which objects are then gonna go and get processed. Because I've already just looked at that with you, I can just approve straight through. So that has also just generated an error for us. This one, I'm pleased to say, was purposely there. So the error was telling me that the policy that we're going to run against was not set valid for redaction in the policy vault. So we've got a specific vault that we keep the redaction policy in, and it's telling me that this is inconsistent. And what that means is that what we're trying to run for has had a change performed to it since the last time it was approved by the relevant approver. So we've got a mechanism here to ensure that if you are changing things and moving them to production, that when you reach production, if there had been an unknowing impact, so you were changing something in your scrambling, but it had impacted the way your redaction was going to work, you would then need to have again another set of approvals in place before you'd be able to actually execute the redaction live in the productive system. So now that I've set that as valid for redaction, this redaction case will now start, and it's gone into the status of scheduled. Now as well as this individual case, we also have a single batch submission. Let me just use the arrow instead. There we go. At the base here. Now the back submission is from our data retain solution. So this is then saying, I found more than one employee. I've got more than one central person that I need to process and submitting that in. But they've got exactly the same choices. It's still only approve and reject, and they need to approve or reject the entire case. Now, obviously, there's some control mechanisms in place to be able to say we need to ensure that the correct people are approving that, that they have the authorization to approve it. So at this point, we do also check the standard SAP authorizations to be able to confirm that the person processing has the right to view employee data within production if they're being given the authority to remove that same data. So as well as product authorizations that will identify yeah. As well as the product authorizations that will identify your access to either be an access request or an approver to redaction or an administrator to be able to administer those policies. We also are checking the standard SAP roles and authorizations to confirm. Now that key that job is now showing as complete, so I can now actually see the trace mess messages. If there was, an error there, I will be able to see what those errors were. And if I now come through back to p a twenty, and the person has had their name changed to John Doe to be very, very clear that it should be removed. Sometimes we actually use the words do not use as their name or redacted or deleted to be able to make it very clear. And consistently, if I come across and I refresh this SAP SuccessFactors record, Sam Jones has also now become John Doe and has had their ID changed from the original, and that photo has also been removed. Some used to have their photo there, but it's been deleted as an attachment to the record that's processing. So as you can see, the control is all taken care of from the SAP system, and that's where I say that we still require that SAP HR system. But we can then link consistently to where that employee is a business partner in CRM or SRM to be able to work in those systems. If it's a SuccessFactors related, we can perform the same integrations and processes to be able to bring that information through as a business process that can be run and managed by via transport management through to the productive system. And we've got a lot of controls in place to ensure that only genuine people that should be passed into the processes can be passed into them. Okay. So coming back to just the last couple of slides, in summary, the five ways we can help. So the first is to be able to say to minimize the number of refreshes from production you need each year. So along with what I've shown you today around data removal, we also have data copy solutions that can copy your employee and employee central data consistently, bring it with scrambling, and do it as deltas to what's been copied from the last instance refresh. And as such, you don't need as many instance refreshes from SAP because you can self provision the data that you need more often, which obviously can reduce the service cost on the SuccessFactors side. It's less disruptive. You're not gonna have system outages while the work is ongoing. As we've discussed, we've already got a standard data map of the standard data within SAP and SuccessFactors that needs anonymization or data removal, but we also have the ability to run our discovery software that will help find and map the custom items and bring that through for implementation to the software. We have the ability to identify a data subject, put them into that password protected PDF, and bring again the consistent data from SuccessFactors and the SAP HR box. The ability to remove information that you no longer have the justification to hold, and scramble that information in the test systems. So as well as the data copy that I mentioned on item one, the item five there can run independently. So if it's more appropriate for you to actually have your instance refresh and then run a scrambling scenario in your systems, the software is available and ready to do that for you. Just included with that is ebook that we prepared on the road to compliance and all of the different things you may like to think see from that. We will share some of these slides following on from the webinar today. So that link will be available for you to be able to download. So finally, I'd just like to turn over for questions. Let's check how I'm doing for time, almost exactly where I was aiming for. So have we had any questions there, Sarah? Yeah. It looks like we've just had one question, but if you have any others, please pop them into that GoToWebinar panel. But someone asked James, is this functionality new, or have you done it before? Oh, of course. Okay. Great question. So, no. The short answer is no. This is not new. We've definitely done it before. So the data scrambling software has been around for around about nine years. The production processing software has been around for about seven years since the advent of GDPR in Europe. So about as you know, that's closer to eight years now as well. And the SuccessFactors integration piece specifically has been around for about five years. So we've had some interesting projects within that time. We've had some clients in Europe who didn't have the on premise SAP system. They were only using Employee Central, and we were able to arrange a way that we would host an ABAP stack that we could run the software in that would connect to their environment and complete the scrambling of just their EC data even though there was no local key. We're currently just finishing off an interesting project out in Australia that where we've been running the retention and reduction in production. But the thing that was interesting here was both they had quite a of custom attachments that had been created, that they were storing images of pass passports and work visas and all sorts of additional items that they have to create some customizations for. So we needed to do some work with them to be able to do the successful removal of them all. But they also rather than treating the SAP payroll system as the master of that retention date and the retention checks, they wanted to do that from SuccessFactors. So we've actually built on the ABAP side the logic to read SuccessFactors en masse to identify the users to submit into our process and then, therefore, find the related employees. So it's the reverse of what I've just shown you to be able to work down the other angle. And then there's been numerous sort of scrambling projects done throughout the US, Canada, Europe, Middle East, Africa, and Asia Pac with both combined systems and even more complex. So I think the most complex that we've done recently was actually a company that I can discuss that was Welsh Water. This was two or three years ago. They had a very complex environment with IS utilities system, with CRM and SRM, a separate HR payroll with an employee mini in the ISU system for finance and vendor and the SuccessFactors instance attached to the HR. And we completed the complete scrambling of all of those systems. I think the final time was sixteen hours, so it was completed to post refresh in less than a day to be able to consistently anonymize all of the different datas. So it's certainly not new. No. I've got plenty of gray hair and scars for that time. We do have a couple more questions, an interesting one here. How will this work if Employee Central has become the system of record and SAP HCM has been decommissioned? So if there is any SAP system still in the environment, it can work exactly as described, that we would still need to create a no data connection, but we do require a system. As I just mentioned in my previous answer, we have had one instance of this where we've actually just temporarily hosted an instance of SAP ABAP to be able to process it through, but it doesn't have to be that it's your HR system. It just has to be an ABAP stack to be able to run the code base. We are working on some direct cloud solutions. So the latest is with Salesforce and Workday to be able to do anonymization there. And they don't actually require the ABAP stack in the same way that our SuccessFactors integration does at the moment. So we will be moving SuccessFactors that way as well to be able to do it where there is only SuccessFactors. But at the moment, we do need an ABAP stack, but it purely is a place to install the code base and then have an OData con connection. It doesn't have to be that your HR data is in there. So it could be your finance system, your CRM, your SRM. It really doesn't matter. It but there does need to be the ABAP stack at the moment. But like I said, there is a road map there to remove that need as well. Okay. Thanks, James. Another one. Would it be possible to cover extensibility apps built in b p BTP or any other custom solutions? The short answer is no. Not as a without a lot more questions around what are the APIs available. Are you using SOAP? Are you using REST? Are you using OData? What sort of data is being stored? Is there a consistency requirement, or is there a just a direct scramble requirement, etcetera. It's so variable for the different applications, and that's why we're focusing on a priority road map for delivery at the moment based on our client base. And so as a company, we've got a couple of thousand repeat clients that we're working with, and we're working sort of through the priority list at the moment. And I say Salesforce and Workday were the first two that came up as complete non SAP solutions. But then we're getting a lot of interest now around Ariba and the SAP Cloud for Customer, which I know still isn't quite what you were asking around custom BTP applications, but we're working through that road map. So it depends on what's available in terms of APIs and integrations. And the new sort of connector solution that we've got Salesforce and Workday is being built within the BTP framework. So that's gonna be available within that framework, but it doesn't mean that the APIs that are built within it would automatically work with any custom developed application. So it would always require a workshop technical appraisal to be able to understand how we can communicate with those instances. Thanks, James, and great questions. Yes. Thank you. Yeah. So I think that's all the time we have. We went a little bit over, but I think we can go ahead and close out. Thank you again, James, and thanks to everyone who attended our session today. And we will be sharing the recording, and please reach out if you have any questions in the meantime, and we will be in touch too soon, and hope to see you at the next one.