Skip to content

Impact Analysis

Note: Impact analysis can be skipped if there are no customizations in the buildplace.


An Impact Analysis is quite similar to an impact assessment in terms of the application on which it runs and the output generated. However, there are significant differences between the two and those are listed in Table 1.1.

Impact Assessment Impact Analysis
Purpose Run before applying a release update to view the effort required to move to the new update. Run after applying the release update to view how the new update applied, has affected the existing customization.
Trigger Point Ideally triggered before applying the release update and can be re-triggered at a later stage as well. Can only be triggered after applying the release update and will be available to be triggered at any point after.
User Input User needs to select the target release update version that they are planning to move onto. User input is not required. The target tag is taken as the release update applied to the customer solution baseline repository.
Table 1.1: Differences between Impact Assessment and Impact Analysis

Behavior of the Release Update Studio Navigator

Once the Release Update is successfully applied to the customer solution baseline repository using the "Apply Release Update" button on the navigator, the "Impact Analysis" and "Order Environment" buttons will be enabled (Figure 1.1).

Figure 1.1 - Navigator with 'Impact Analysis' and 'Order Environment' buttons enabled

Trigger Impact Analysis from the Release Update Studio

A click on the "Impact Analysis" button will download the .upda file for impact analysis. There is no impact on the user journey from the structure of the Impact Analysis file. This content is visible only if user view the .upda file. The file includes repository information needed for Update Analyzer to run the analysis. The parameters included in the file are (Figure 1.2):

  • The Base tag [1]
  • The Target tag [2]
  • Core Code Repository URL [3]
  • Baseline Repository URL [4]
  • Baseline Repository branch name [5]
  • Solution Repository URL [6]
  • Solution Repository branch name [7]
Figure 1.2 - Parameters included in the .upda file

Although the target tag was taken as a user input in Impact Assessment, no user input is taken in Impact Analysis. The target tag is considered as the release update version applied to the customer solution baseline repository.

The Effect on the Release Update Summary Table

If the file is successfully downloaded, the status of the Impact Analysis record in the Release Update Summary table will be marked as “Initialized” [1].

The Release Update summary table will further record the “Date started” field [2] with the date the .upda file download was triggered and the “Last Modified By” [3] field with the email ID of the user who triggered the impact analysis (Figure 1.2).

Figure 1.2 - Release Update Summary Table updated with the Impact Analysis progress

If the file fails to download, the status will be marked as “Failed” in the Release Update Summary table (Figure 1.3) and the user is required to download the .upda file once again.

Figure 1.3 - Impact Analysis status recorded as "Failed" in the Release Update Summary table

Trigger Impact Analysis using Update Analyzer

A similar flow as impact assessment needs to be followed for the impact analysis to be triggered.

Refer the following section: Trigger Impact Assessment using Update Analyzer.

As an impact analysis can be performed only after applying the release update to the customer solution baseline repository, the “Impact Analysis” button will be enabled from the time of successful completion of applying the release update until the end of the release update process.

Impact analysis will list the impacts for solutionset.yaml file, translation.usage.json file and customized files. These should be handled during customization upliftment.