Skip to Content
Technical Articles
Author's profile photo Kirill Leventcov

Moderating user input in SAP Build Apps


When developing an application or making a website, it is important to moderate user behavior to not only prevent potentially incorrect input, but also to make the usability better. In this blog, let’s explore several ways this can be achieved in SAP Build Apps. The methods will include configuring view components, using formula functions and passing through AI.

Component properties

Most of the input-oriented components are equipped with properties that allow you to filter user input. For instance, the Input Field can be configured to automatically capitalize each word:

That way, you can enforce a requirement of capitalizing each word without adding extra instructions for the user. Another great feature of the Input Field is the ability to define the Keyboard type, which introduces a great level of user experience. As a user, I will be satisfied to see a numeric pad when I need to enter my phone number, instead of the regular keyboard.

Admittedly, that might not be enough, as users can still enter anything they like in the input field. If your input requirements are strict, look into providing a part or even the whole input to the user, mitigating potential errors. A Dropdown Field is a perfect option. As an example, you can supply a phone number code in a dropdown to remove confusing with the format, as different users can have a different way of typing their number. See an inspiration below:


Formula functions

While defining component properties might be enough for some use cases, in the majority of cases we want to further moderate user input. Here, Formula functions come in play. With a variety of functions, we can not only check if the input is correct, but also modify it to avoid prohibited content.

For the first use case, let’s extend the capabilities of an Input with “Password input” property set to true. With the formula, let’s enforce the following password rules:

– At least 8 characters.
– Must contain at least 1 uppercase letter, 1 lowercase letter, and 1 number.
– Can contain special characters.

Here is the formula that does just that:

MATCHES_REGEX(" ", "/^(?=.*\\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[a-zA-Z]).{8,}$/gm")

Put the text you want to match between the first quotation marks, or substitute them with the variable. The formula will return true if the password matches the above criteria, and false if not. You can put this formula in an IF flow function to interrupt execution of further logic in case the password does not match:

Next, let’s protect our users against Cross Site Scripting (XSS). In short, it is a web vulnerability that allows a malicious user to inject custom scripts into your website, targeting users or the server. The most common example of XSS is putting a <script>...</script> tag into an input field, with ... substituted with a payload. This is particularly dangerous if you allow users to post publicly, which potentially may allow a hacker to execute this payload against hundreds of people.

Thankfully, there are ways to mitigate that, and formulas, again, will help us. We can use REPLACE_ALL_REGEX to replace the script tag with a regular expression:

REPLACE_ALL_REGEX("Hello <script>alert(1)</script>", "<.*?script.*\/?>", "")

Notice how the script tag with the payload disappears, leaving no malicious trail behind. Alternatively, you could, again, use MATCHES_REGEX to even disallow input with a script tag.

But what if a user decides to use XSS in a less malicious way, for instance, to format their text with the <h1> tag? For that, we have a STRIP_HTML_TAGS formula. It returns a given text with all HTML tags removed, preventing any formatting attempt:

STRIP_HTML_TAGS("<h1>Hi everyone!</h1><span style='color:red'> My text is red</span>")

Notice, again, how the HTML tags are not included in the final output.

AI Moderation

All the methods described previously are highly technical and are based on predictions made about user’s potential behavior. Although, since our users are humans just like us, they can be highly unforeseeable. Gladly, with the use of Artificial Intelligence, we can detect potential malice in user’s input and mitigate it before they even submit it. Again, we cannot put all the harmful words in a deny list, as people will find their ways around it, but with AI moderation we can at least increase the scope of detectable abuse.

For thy purpose, we are going to use OpenAI’s Moderation API. Check out my previous blog for a more in-depth guide about using OpenAI in SAP Build Apps. As can be seen from the example usage:

curl \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -d '{
  "input": "I don't like this post"


We need to provide two HTTP headers: Content-Type and Authorization. And the body of a request is a JSON object, with a single input key inside.

Create a new REST API data resource, and set the “Resource URL” to Go to the “Create Record (POST)” tab and add moderations to the end of the URL. Then create two HTTP Headers as described in the request above, substituting YOUR_API_KEY with a key obtained from OpenAI:

Navigate to the Schema tab and choose Custom schema for “Create record (POST) request schema”. Add a property named input, type Text. Next, go to the Test tab, open the Record properties and put anything in the input field to test your connection. Click “Run Test” and once you get a response, choose to “Set Schema From Response”. The Schema tab should look the following way:

Your integration is now ready, and you can start using it in your app. Although note that using data variables is not a great option, as they, by default, will send this request every 5 seconds.

The AI will check the input against a series of potentially harmful topics, with the value for each being between 0 and 1, where higher values denote higher confidence.


This blog could have gone much further and be as long as a book, since there are so many ways you can improve your application by moderating input. With that, I encourage you to treat the instructions presented as more of an inspiration and expand upon them.

If you know any other methods that others may find beneficial, feel free to add them to comments 👇

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Raoul Shiro
      Raoul Shiro

      Hello Kirill,


      I am testing calling the Openai moderation API, followed your guidance, I am getting a response in the REST API Test utility.  But I cannot seem to retrieve that response using data variables for example, I could only set variable values (POST) ....

      Is the only alternative to use "HTTP requests" Component (instead of REST API Data Source) to retrieve the response from a POST call ?

      Author's profile photo Kirill Leventcov
      Kirill Leventcov
      Blog Post Author

      As mentioned in the blog, it is not optimal to use data variables with this API. My implementation was done with a Create Record flow function. You can then put its output to a page or app variable.

      Author's profile photo Mark Fogle
      Mark Fogle

      Hi Raoul,

      As Kirill mentioned, data variables aren't ideal in this case, mostly because they make use of the GET Response schema, even for POST Requests.  So you would have to duplicate the POST Response Schema (or at least part of it) in order to take this approach.

      In my blog that uses the Open AI Chat Completion API, I provide an example of using a page variable instead (one of the alternatives that Kirill proposed).



      Author's profile photo Raoul Shiro
      Raoul Shiro

      Hello Mark,


      Thank you for the astute and detailled answer.

      I followed your blog, and indeed assigning a page variable to a formula that would retrieve the openai post response works fine. I had been stuck on this for weeks. Thanks !