A Look at the Automation Editor in SAP Build Process Automation

When we talk about automation artifacts in SAP Build, we’re referring to automations created in the automation editor.

In this blog post, we’ll discuss how to use the automation editor to create an automation artifact. We’ll first explain the different features available on the automation editor’s screen and then how to begin using these features to design an automation flow. We’ll also discuss how to test and debug an automation with the automation editor.

Overview

The automation editor has the following features, as shown in the figure below.

1. Automation editor canvas: The automation editor canvas is where you design your automation. Here, you can drag and drop activities in the sequence needed. You can also click on specific activities to get more information about the activities or to change their parameters.
2. Automation Details (right-hand panel): If an activity from the canvas is selected, the activity details and parameters will be shown here. However, if no activity is selected (or you click the automation editor canvas), the Automation Details area appears (as shown). This is where you can add any of the activities or options from (4) through (10) to the automation editor canvas. You can also toggle this pane to the Input/Output Doing this will allow you to set inputs or outputs for your automation artifact. You can also select the Info option in the pane to display and adjust the automation artifact information, such as its name or timeout duration (for both specific activities or the entire automation).
3. Search bar: You can use this search bar to search for specific activities or options from (4) through (10) that you may want to drag into your automation editor canvas.
4. Action Groups: You can call configured actions from your automation artifact. Any actions inside the project (can be added as dependencies in the project settings) will be available to add from here.
5. Automations: You can call already-created automations from your automation artifact. Any automations inside the project (or those added as dependencies in the project settings) will be available to add from here.
6. Screens: You can automate on top of the UIs of different applications. You first need to capture the applications and their corresponding screens and elements inside the application editor. Once you’ve captured these items, you can drag and drop the screens onto your automation editor canvas and add activities to them.
7. Activities: Activities are predefined by the SDKs inside your project. You can easily add SDKs as dependencies to your project based on the types of activities you want to use. You can then drag and drop their associated activities onto the automation editor canvas.
8. Processes: You can call already-created processes from your automation artifact. Any process inside the project will be available to add from here.
9. Data: Data types and data management activities can be added to your automation artifact to manage data and variables throughout the automation flow.
10. Controls: Controls can be used to create complex automation flows with conditions (if . . . else), iterations (loops), and error handling. You can drag and drop different controls into your automation editor canvas.
11. Design Console: The Design Console will alert you to any errors, warnings, and information that arises while designing your automation artifact. For example, if you add an activity but forget to fill out one of its required parameters, an error will occur in the Design Console.
12. Test Console: The Test Console will alert you to any errors, warnings, or information that arises while testing your automation artifact. For example, if your automation fails during execution because you improperly used an activity, an error will occur in the Test Console. You can also print messages (and variables) to the Test Console using the Log Message
13. Variables: You can keep track of all variables associated with your automation artifact here. You can see the variable name, associated step or activity, type, and whether the variable is a list. You can also set the variable as a watch variable so you can monitor its values throughout the automation flow during testing.
14. Breakpoints/Watches: You can keep track of the different breakpoints and watches (or watch variables) throughout the automation flow during testing. This is part of the tester panel.
15. Timeline: The timeline shows the event logs of the automation flow during testing. You can also interact with the timeline by clicking on specific events to get more information. This is also part of the tester panel.
16. Tester (debug) panel: This icon opens the tester panel.
17. Start test (debug): This icon starts the test (debug) session for your automation artifact. If you have input variables, you’ll be asked to provide values.
18. Automation toolbar: The automation toolbar contains multiple tools to help design and edit your automation artifact. You can also access most of these tools by right-clicking activities or groups of activities and using the corresponding dropdown list.
19. Settings: This icon opens the Settings popup, where you can edit many aspects of your project. This is where you can add dependencies to your project, such as SDKs, to increase the functionality and types of activities you can add to the automation editor canvas. You can also look at general settings, share your project, edit environment variables, change the agent version, and add agent attributes. 

Note: The Screens, Automations, Action Groups, and Processes dropdown options in the right-hand panel won’t be available if they are empty. If they haven’t been created yet, there’s nothing to be shown.

To create an automation artifact and get started inside the automation editor, you can navigate to the Overview section, click Create, and choose Automation. You can give it a Name, Identifier (automatically chosen, but you can edit it), and Description.

Using the Automation Editor

Now that you’re familiar with the automation editor, let’s take a step inside and see how to begin using it to accomplish your automation. Prior to creating anything inside your automation editor, architect your solution and create a flowchart (pen and paper will do) to understand the basic flow of activities you plan on automating. This will help you better understand the activities you want to use, the SDKs you want to add, and the applications you want to capture

Of course, your preliminary flowchart doesn’t need to be perfect and may not map 1:1 with activities available in the automation editor. As you become more experienced with automation, your preliminary flowcharts will naturally begin to map more closely with what is available. Over the course of the implementation, you should test, validate, and iterate many times to find the correct flow of activities to accurately execute your automation.

Once you have an idea of how you want to design your automation flow, you can begin using the automation editor to implement it. The already-created but empty flowchart (with the Start and End buttons) is where you’ll drag and drop any of your activities to begin designing (see figure below). To do this, click the activities on the right-side panel (or search for specific activities), and begin dragging them into the flowchart.

Once you drag and drop an activity inside the flowchart, you’ll likely want to edit its properties. To do this, click the activity, and its properties will appear on the right-hand panel. Here, you can use any variables already created in your project or that were brought into the project as inputs or environment variables. You’ll see the recommended list of available variables to be used by clicking inside one of the activity parameters, which will produce a dropdown list of the variables. You may notice that some variables in this dropdown have a number or letter next to them, as shown here.

This number represents the specific step that the variable was created from. This step number corresponds to the number to the left of each of your activities. Input variables will receive a 0 designation, while environment variables will receive an E designation. Some variables may also be grayed out. This represents that the variable is of the wrong type (e.g., the parameter is looking for a number, but the variable is a string).

You’ll also see the pencil icon, which allows you to open the expression editor to designate your own values inside the activity parameters. For some activities, you can even create more complex logic or expressions that may not be possible from outside the expression editor.

You should also be aware that when there are errors with your automation from a design-time perspective, they will show in the Design Console at the bottom of your screen, as shown in the next figure. You can usually just click the error, and it will automatically take you to the activity and its associated error. You’ll need to solve all Design Console errors before you can test your automation.

Another benefit of outlining the flow of your automation prior to building it is that you can have a general view of what data you’ll be using. While this can always change over the course of your implementation, it’s good to have a general understanding of what data you’ll need, what data you’ll create, and what data you’ll output. Often, an automation artifact is only one part of the larger process. Sometimes, multiple automation artifacts can be chained together, and an automation is often combined with the other artifacts described in this book. To make use of this powerful, modular approach, you need a way of passing data between your different artifacts and you need a good way of using data available from previous artifacts inside your automation artifact.

Let’s say, for example, we wanted to use an invoice number that we collected from a form artifact earlier in our process. We can set that as an input to our automation to be used by the automation’s activities. Then, during the automation, we used our document understanding capabilities to read that specific invoice and extracted all relevant information. We could then set this information as an output of our automation to be used later in the process, such as in an approval artifact. To do this, we need to click the Input/Output toggle on the right-side panel from within the automation, as shown in the next figure. From here, we can define the variable names and types to which the data will be assigned (and later assign them by clicking the End node in our automation flow). We’ll then be able to use all inputs over the course of the automation and all outputs from outside the automation in other artifacts.

Testing and Debugging from the Automation Editor

Understanding how to test and debug your automations is extremely important to implementing your automation flows. You should strive to test and validate early and often, iterating as necessary. You’ll find over the course of implementation that, especially with complex functionality and flows, activities may not perform exactly as you expect them to. Perhaps you might notice that an activity requires case-sensitive strings or that an application doesn’t respond quickly enough, requiring you to add a delay. There are a countless number of unpredictable issues you may run into that are best caught early so that they don’t compound and create complex issues that are more difficult to solve later.

When you test, you want to make sure you’re considering possible corner cases that may cause your execution to fail. When thinking of corner cases, it’s often helpful to consider what an end user with no knowledge of how the automation is designed might use that could cause an issue. What input might they provide that unknowingly causes the automation to fail? Remember, you may plan on deploying your automation to many users. And, while many users will use it exactly as intended, some may not. Thus, you want to make your automation flow as dynamic as possible and consider all reasonable corner cases when testing. Further, when debugging, you want to reduce the number of things that may cause an issue. To do this, again, it’s best to test early and often so that you can narrow down the list of troublesome cases as much as possible.

To test your automation, click the play button inside the automation editor. This will launch a popup that allows you to fill any fields relating to environment variables or input variables that may be used during the automation flow. Once you click TEST, your automation will connect to the locally installed desktop agent where it will begin executing the automation.

When testing your automation, it may also be helpful to use breakpoints to pause your test at specific points during execution. This may be because you need to configure something to test a specific functionality during execution or because you want to inspect specific variables or elements prior to or immediately after specific steps. To inspect variables, you can set watch variables or use the Log Message activity to log a variable or other message.

In the next figure, we’ve created a simple automation where we loop three times, logging a message every time. We’ve set a breakpoint on the Log Message activity, where the execution will pause during every iteration (you can Resume, Step Over, Step Into, and Step Out of each activity/module with the buttons at the top of the debugging pane).

You can also see a timeline of activities in the debugging pane, where you can click into any of the specific activities and get more information, as shown in the final figure. This is particularly helpful if a specific activity has an error during execution. That activity will show as red in the timeline. You can then click the activity and receive information on what the error is related to.

Testing and debugging automations is a very important skill to develop during the design of your automations. It not only helps you to create robust and powerful automations but also allows you to iterate with new functionality more quickly. Ultimately, being able to quickly test and iterate allows you to create better projects more efficiently.

Editor’s note: This post has been adapted from a section of the book SAP Build Process Automation: The Comprehensive Guide by Steven Jacobson, Chaitanya Priya Puvvada, Seshadri Sreenivas Ramanarayanan, Stephan Schluchter, and Archana Shukla. Steven is a product manager at SAP who has in-depth knowledge of and expertise with SAP Build Process Automation. Chaitanya is a senior product manager in the human capital management domain with SAP SuccessFactors. Seshadri is a senior product manager for SAP Build Process Automation at SAP. Schluchter is a product manager for SAP Build. Archana is a senior director of product management at SAP.

This post was originally published 4/2025.