Fine-Tuning of Custom Situations: Configure the Layout of My Situations – Extended
My name is Angelika Salmen and I am the product owner of Situation Handling. With this blog post I want to guide you through the detailed configuration steps of the My Situation – Extended app so you can make the most of it and enable users to optimize business processes.
The configuration relates to the extended framework for Situation Handling which has been available since SAP S/4HANA Cloud 2202 and SAP S/4HANA 2021 FPS2.
Daily business can face multiple issues such as overlooking deadlines, delays, or missing out on follow-up activities. This can lead to higher costs, frustrated users, or even loss of customers. Situation Handling detects these issues and helps you optimize the business processes.
Enable users to optimize business processes
To achieve the best impact for your business, you want to support users in the best way possible. The My Situation – Extended app displays all situations in a user’s area of responsibility. The situation page fosters a quick processing of the situation by providing focused data and solution proposals. I recommend carefully designing the information displayed about a situation. Only well-informed users can make good decisions in a timely manner and improve your business.
Custom layout of the My Situations – Extended app
The My Situation – Extended app contains detailed information about situations. In addition to generic sections, you have multiple options for customizing the layout.
Situation Handling’s modelling approach is based on high reusability. This means there are layout sections that refer to the situation scenario and others to the situation type.
The situation scenario represents a business scope from which several use cases with similar patterns can be derived. The scenario has one anchor object that is affected by the situation. As it’s the same for all derived use cases, you can conveniently configure the layout related to the anchor object in the scenario. There can be many trigger objects in a scenario and you can define the corresponding layout sections for each situation trigger. Use cases related to a trigger object reuse its layout configuration, too.
The situation type represents a use case. Here you define specific texts that describe the situation. The texts can contain variables. The data shown in the My Situation – Extended app reflects the state at the time the situation is detected by the system. It captures the state of the instance and the circumstances that triggered the situation so that users understand why the situation occurred.
In the situation type, you also select the actions that help the users resolve the situation.
Layout of the list view
The list view on the entry screen of the My Situation – Extended app contains predefined and customizable parts.
Predefined layout of the list view
The navigation pane shows all scenarios with active situations, which means instances with the status openor in progress.
When no specific scenario is selected in the navigation pane (All), the filter area displays generic filters that apply to all scenarios as well as to the Search field.
The Situation, Status, Processor, and Scenario list columns are also displayed by default.
Custom layout of the list view
Generic list view (All scenarios)
When all scenarios are selected, the table shows additional information for each situation instance in the Key Information column. You define the key information for the situation scenario for each situation trigger in the Fields in List Page section. The graphics below show the configuration of the situation triggers Periodical Flight Check and Booking Created in the Flight Profitability demo scenario.
The first example refers to the Periodical Flight Check situation trigger in which Flight is both the anchor object and the trigger object. The situation trigger is used in the demo cases Critical Eco Index and Low Ticket Sales. Accordingly, both cases show the same type of data in the Key Information column.
The second example shows the situation trigger Booking Created. Its anchor object is Flight and its trigger object is Booking. The situation trigger is used in the Overbooking demo case. The Key Information differs from other demo cases because it contains data from Flight and Booking.
When selecting a specific scenario in the navigation pane, the list view filters the corresponding situations. Again, the columns Situation, Status, Processor, and Scenario are displayed per default, while the filter area contains only Search and the Status filter. To support the end user in the best way possible, you add scenario-specific information.
You can add one column for the anchor and the trigger object. This applies to the scenario and you configure the columns in the List Page Layout section. The anchor object is always the same within a scenario, therefore the column label can be specific. In our example it’s Flight. If a scenario contains multiple trigger objects, the column name should be something generic like Additional Information.
The data in the columns is trigger-specific and you define it in the Fields in List Page section. You can select a maximum of four fields for each object. In the example below, the fields Airline Code, Connection ID, Flight Date, and Plane Type are selected for the anchor object. The fields Sales Rate, Seating Occupancy, and Eco Index are selected for the trigger object. They are visible for all situations that are based on the Periodical Flight Check trigger.
You can also add each of these fields as a scenario-specific filter. If you configure filters for the different situation triggers, then all of the filters are visible in the scenario-specific view. In the graphic above, you can see the filters defined for the Periodical Flight Check trigger as well as for Booking Created.
Layout of the situation page
The layout of the situation page follows a specific structure: header, trigger object and anchor object details, solution proposals, and related apps. Only the header is predefined while all other sections are custom configurations.
Predefined layout of the situation page
The header of the situation page is rendered by default. It contains the description of the situation, which is also shown in the list view, the status, and if applicable, the assigned processor. The time indicates when an instance was created.
The header is followed by data from the trigger object and the anchor object. Like the list view, you define the section for each situation trigger in the situation scenario. You can either define only one section, for example, for the anchor object, or you can define a section for each object. A section can have further subsections as shown for Flight in the graphic below. I recommend starting with the more situation-specific data which is usually the trigger object data.
The action sections Solution Proposals and Related Apps are visible only if you define actions in the situation type.
Use case-specific content
The content is use case-specific. You define it in the Manage Situation Types – Extended app. This includes the texts, the data of variables, and the end-user actions.
In the situation type you can define the texts for each condition. I recommend writing meaningful texts that help the users understand the concrete situation. You can also provide guidance for dealing with the situation, either in the description or, if applicable, by adding a link to a website with more information. This could be a reference to a handbook, for example.
Below you can see a sample configuration of the Sales Rate demo case. When the system detects situations matching condition 2, users see the text of the assigned situation display 2.
The texts can include variables with data from the anchor and trigger objects. You choose the data from underlying CDS views. If you choose to hide fields in the scenario section Hidden Fields in UI, they aren’t visible in the dialog.
Special case: trigger accumulation
If you enable trigger accumulation in a situation type, instead of creating single instances for each trigger, users get only one instance that includes all triggers. The triggers are listed on the situation page. The selected trigger displays the related data you configured in the situation page layout.
As long as the situation instance exists, the system can add and remove triggers when circumstances change. The system captures the context data of the trigger and anchor section at the time the trigger creates or updates the situation, so that users understand why the situation occurred. The triggers that occurred at different times may show different context data in the trigger and anchor sections.
For example, the first overbooked passenger creates a situation. The trigger data contains booking details like Passenger Name and Booking ID. The flight data shows sales numbers and the occupied seats at the time the overbooking occurred (the economy passenger Latoya Wu is number 34 of 33).
The next overbooking happens hours later, and the flight data has already changed. The economy passenger Izuki Wambugo is number 35 of 33. One more business class seat is occupied, and the sales data has increased, too.
The user actions displayed in the sections Solution Proposals and Related Apps are use case-specific. You define the actions in the situation type. Solution proposals are callback actions that close a situation. The Related Apps section contains navigation options to business apps. You configure the actions in the corresponding sections of the situation trigger.
Actions can be trigger-specific, which means each trigger could render different actions for the situation page. For example, a booking action can be applied only to the booking object.
Other actions could be relevant for all situation instances, independent of the trigger. These actions must relate to the anchor object, and you can define them as general actions. They appear automatically in the situation trigger sections and can be sorted by relevance.
For example, let’s assume both the flight object and the booking object can trigger a booking issue. In both cases the anchor-related (flight) actions Change Plane and Manage Flight could help solve the situation. You define them as generic actions. If the booking object triggers a situation, additional actions can be helpful for users. You define them as trigger-specific actions. The graphic below shows the relationship between generic and trigger-specific actions.
Now you’re all set to enable your users to create a positive impact on your business.
If you want to learn more about the extended framework for Situation Handling you might also like:
- SAP Help Portal: Situation Handling – Extended Framework for SAP S/4HANA Cloud, Situation Handling – Extended Framework for SAP S/4HANA
- SAP Community: Intelligent Situation Handling
- Blog post series: Custom Situation Cases: Configure Your Own Use Cases (1/6)