My name is Angelika Salmen and I am the product owner of Situation Handling. With this blog post series, I want to give you guidance about how to start creating your own situation use cases. After you’ve designed your detailed use case and mapped it to the application artifacts, let me now show you how to design your situation scenario.
High-level scenario design
A situation scenario represents a business scope from which you can derive multiple use cases (situation templates).
A scenario always has one anchor object that is affected by the situation.
A scenario can have multiple trigger objects that cause the situation.
A scenario refers to a Responsibility Context that is the basis for identifying the users who are informed about situations.
You can derive multiple use cases (situation templates) from one scenario.
The use cases bundled in a scenario need to belong to the same business scope.
The use cases bundled in a scenario need to use data similar to that of the anchor object that is displayed as contextual information on the situation page in the My Situations – Extended app.
Here are some examples of scenarios that support multiple use cases:
A contract can expire, can soon be consumed, or is no longer suggested for use because the performance rating of the supplier has dropped. In all cases, the situation is displayed on the contract.
The trigger can be the contract itself or the supplier status.
Relevant contextual information includes the contract details, supplier rating, and contact data.
A flight can be affected by various issues: ticket sales are too low, the eco index is too high, or economy class is overbooked.
The trigger can be the flight itself or a booking.
Relevant contextual information includes flight details such as the airline, connection, flight date, ticket sales, and seating information. It also includes booking details such as the booking ID and passenger name.
A service appointment is dependent on available material and service staff. A material can be delayed or not be available and need substitution. The service staff might be rescheduled or not be available because of sick leave. Or even worse, there could be issues with the material and the staff.
The trigger can be the missing material or not enough staff.
Relevant contextual information includes the material details such as price and delivery period. It can also include staffing details, such as expertise and availability.
In the scenario you also define the custom layout of the My Situations – Extended app that contains the contextual data from the anchor and the trigger object.
Here you can define custom columns for the anchor and trigger object.
You can also select fields from the custom columns you want to filter by.
You can define sections for contextual data from the anchor and trigger object, each having a dedicated section with optional subsections.
When you first design a scenario, I recommend starting with a concrete use case.
Simplest case: variations of a situation case
If you want to start with only one situation case, you simply need to add the objects and their events and actions to the scenario that you need for your use case.
Defining a scenario in addition to the template allows you to easily create variations of your use case.
Example: Expiring License
You want to check the expiration date of a license and have defined a batch-based use case that informs the user one week before the license expires.
Send a warning in advance with instructions on how to proceed best.
By using the same anchor and trigger, you can also derive further use cases (situation templates):
Add a template with enhanced conditions that sends an early warning and another warning close to the expiration date.
Add a template that informs the user that the license has already expired with alternative instructions.
Group situation cases with the same anchor object
If you have identified multiple use cases with the same anchor object you can combine them in one scenario. The use cases can be based on the same or on different trigger objects.
The use cases should use the contextual data from the anchor object because it is used for all derived situation templates. The contextual data from the trigger object is specific but will also be reused for all templates that use the same trigger. In addition to the custom layout of the My Situations – Extended app, the data is also used for filter conditions and variables for situation texts.
If your situation cases use data different from that of the anchor object, the cases probably address different business scopes. If you use the same trigger for multiple use cases but need to display different contextual data to the user, the use cases probably belong to different business scopes. I recommend creating different scenarios with a clear business scope because:
It’s easier for you to think about all the artifacts that you need in order to support the use cases.
It’s easier for other users who create new templates to understand the scope of the scenario.
Enhancing an existing scenario
When you’re familiar with the situation scenario concept, you can start enhancing existing scenarios with further triggers.
Reflect the business scope of your scenario and check whether there might be further elements that would fit the business scope and provide more flexibility for creating situation templates.
Think about further trigger objects that might be relevant.
Add all meaningful trigger object behaviors such as create, update, and delete.
Consider both event-based and batch-based triggers.
With the richness of your scenario the flexibility of derived templates increases, but keep in mind that scenarios need to have a clear business scope to be easily used.
Start from scratch
Finally, you can also start thinking about the pain points of your business processes and derive the related objects.
Cluster pain points belonging to the same business scope.
Identify the objects that are involved in a business scope.
Define the relevant data from the objects that is needed to configure conditions and to inform the end user about the situation details.
Refine the relationships of the objects.
Which objects are affected by a situation (anchor object)?
Which objects trigger a situation (trigger object)?
Which object data is relevant?
Group objects with the same data.
Pain points that affect the same anchor object and focus on the same data qualify for a scenario.
A scenario is assigned to a responsibility context. The context includes team categories and / or rules that determine the users who are informed about a situation.
Recipients by teams are identified by the team category. Each team configured in Responsibility Management with the corresponding category is informed about the situation. You can use filters to narrow down the target group and inform only specific team members.
Recipients by rules are typically used for the identification of creators, approvers, and so on.
Follow these steps to configure the responsibility context and the related artifacts.
Teams: You can use standard team categories or custom team categories that you create with the Manage Team Categories Custom team categories require a custom context and you need to configure team types, responsibility definitions and functions with CBC, and you need a custom context.
Rules: You can use standard rules or create custom rules with the Manage Responsibility Rules The custom logic is implemented via a BAdI. The rule definition is twofold:
The responsibility context includes the unique agent rules that contain the data source mapping. The agent rules are then mapped to responsibility rules.
The responsibility rules include a rule ID and parameters and they can be mapped to multiple agent rules.
End user actions
The scenario should include all reasonable actions that are supported by its objects. The actions are displayed on the situation page of the My Situations – Extended app.
Callback actions that are displayed as Solution Proposals.
Navigation actions that are displayed as Related Applications.
You have two options for configuring the actions:
Anchor object actions can be configured as General Actions. That means they are available for all anchor-trigger combinations.
Trigger object actions are always trigger-specific.
Custom layout of My Situations – Extended
In the scenario you also define the layout of the situation page and content for the custom list views of the My Situations – Extended app. It’s based on the data of the anchor and trigger objects.
Anchor object – the data is used for all use cases derived from the scenario: