Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 2 of 6

Standard automates and customization

17 min

Listen to this lesson

0:00 / 5:50

SAP's preconfigured automates are a head start, not a finished regression suite. They describe SAP's standard version of a process with SAP's standard screens and fields. The moment you configure that process differently, add a field, use a different app or extend the logic, the standard automate may no longer match what your users actually do. SAP Learning says it directly: when a process, application or UI field is customized, the related automate must be updated to match.

Standard, custom and post-upgrade

Standard automateCustom automateSAP post-upgrade test
Who builds itSAPYour team, usually by copying a standard oneSAP
What it coversSAP standard process as deliveredYour configured process, fields and extensionsStandard, unchanged processes
Who runs itYou, in your test plansYou, in your test plansSAP, after each upgrade, with your consent
Who maintains itSAPYou, after every relevant changeSAP
Three kinds of automated tests around the Public Edition upgrade.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

From standard to custom

The normal path is to start from the standard automate for the process, copy it, and adapt the copy so it reflects your configuration. Work with the configuration expert who set the process up, because they know which steps, fields and values differ. Typical adaptations are a field your company makes mandatory, a different default, an additional step for an extension field, a value from your organizational structure such as company code 1710, or a removed step for an app you do not use.

  1. ConfigureThe process is configured in the test system after Fit-to-Standard.
  2. CompareRun the standard automate; note where it diverges from your configured flow.
  3. CopyCreate a custom automate from the standard one.
  4. AdaptChange steps, fields and data to match the configuration and extensions.
  5. ProveRun it green in the test system and review evidence with the key user.
  6. OwnRecord the owner; update it whenever the process changes.
Turning a standard automate into a maintained custom automate.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

Build them as you configure

SAP's guidance is to set up each automate as soon as the related process is configured in the test system, rather than at the end of the project. The reason is the calendar: most implementation projects hit at least one release upgrade before go-live, and an automate ready at that point turns the upgrade from a manual regression scramble into a run of a test plan. It also prepares the customer to maintain the automates after go-live, when regression becomes their responsibility.

Treat each custom automate like any other piece of testware. Give it a name that says which process and variant it covers, write down which configuration decisions it depends on (for example a mandatory field, a pricing condition or an output type), and link it to the requirement or process in SAP Cloud ALM that it proves. When a configuration expert changes one of those decisions, the dependency list tells everyone which automates must be rerun and possibly updated. Without that list, the first sign of a stale automate is a red result in the middle of an upgrade window, when there is least time to investigate.

A dependency list turns a configuration change into a known rerun list instead of a surprise in the upgrade window.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

Release compatibility

In a test plan, the tool shows a Release Compatibility indicator per step. SAP Learning describes standard steps marked with a check mark and custom steps marked with a question mark, meaning they need validation after each release. Treat every question mark as a task in the upgrade window: run it, confirm it still matches the upgraded screens and logic, and fix it if not.

Every question-marked custom step becomes a task in the upgrade window: run it, confirm it, or fix it.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

What would you do?

In the Public Edition what-if, Contoso's configuration expert added a mandatory extension field "Fleet Contract ID" to sales orders. The standard sell-from-stock automate now fails at the save step in the test system. What should happen?

Key points
  • Standard automates represent SAP's standard process; customization means the automate must be updated.
  • Copy the standard automate into a custom one, adapt it with the configuration expert and assign an owner.
  • Build automates as each process is configured; an upgrade will likely arrive before go-live.
  • Custom steps show a question mark for release compatibility and need validation after each release.
  • SAP's post-upgrade tests cover only standard, unchanged processes.

Check your understanding · not graded

Lesson check

  1. 1. What must happen when a customer customizes a field in a process covered by a standard automate?

  2. 2. When does SAP recommend setting up each automate during an implementation?

  3. 3. What does a question mark in the Release Compatibility column indicate?

  4. 4. Which processes do SAP's post-upgrade tests cover?