It's pretty seamless with SAP and Salesforce because they've built in the field definitions and all the things that you need. You literally turn it on and execute your script and it records it. It's very simple. Then you can go back and put in some of the other functions. For example, instead of hard-coding field selections, you put in a data table so you can run it multiple times or with multiple data. It was actually written to work very well with SAP. Salesforce came a little later. Obviously, big companies like ours don't just use SAP. We have integrations with Salesforce and CRM and CPQ and all these other programs that integrate with SAP. Worksoft started looking at its customer-base and saying, "Okay, what are the popular ones you guys use?" Salesforce was one that came up. So one of their releases, about a year or so ago, included the ability to record in Salesforce like it has for SAP, so it's super-easy. We’ve used the Capture not only to train people on how to do things, but also to provide the output to our users so they can validate that what we tested was proper. Capture is very good. It is lengthy, though, because it documents every keystroke that you do. At the beginning it will list all the field selections that we use and then it will give you each step: what it is, pass or fail. If we put in a screenshot, that shows up. It's up to you as to whether you put in screenshots or not. A lot of the times the documentation we provide as a PDF is lengthy but it's also very thorough, which is good. Certify provides codeless, end-to-end process automation across packaged applications. It works well with SAP and Salesforce, for example. Another one that they have done all the definitions for is Oracle. We haven't started on our Oracle ERPs yet, but it's good to know that we can. We just don't have automaters who know Oracle, so we're sticking to what we know right now. The process automation makes for relatively fast automation compared to the other tool that we've tried to use. It makes it so much easier because you don't need any technical programming knowledge. A lot of the other ones are Java-based or based on other tech languages. That's a skillset that the average tester or support person does not have. It makes it very easy for those guys and the learning is quicker too, because the troubleshooting is easier. You look at the code, you can read what it's doing. You understand the business process and you say, "Okay, that's failing because we failed to set this flag, or fill out this field." It’s pretty simple.
