SAP Solution Manager ITSM Package of Action Cards (Intelligent Decision Dimensions Add-on) is designed to provide emailing framework for service management process. The solution provides a package of features allowing working directly from email without having to get access to the SAP system. In particular, these activities are sending notifications and confirmations, creating incidents and tracking their history, attaching files and using multilingual support with SAP Translation HUB integration, etc. The greatest benefits of using Action Cards for our customers lie in simplifying and speeding up decision-making process, cutting down on operational costs, mitigating the loss of productivity and recovering all investment costs within one or two months of intense operation.
Here are the key features of SAP Solution Manager ITSM of Action Cards (Intelligent Decision Dimensions Add-on)
An issue is created with an appropriate subject. If the email text and attachment are included, they will also be recognized and attached to the ITSM Issue.
4483 Solman API :: PPF Action :: Notification Email Method
Actions performed in ITSM can be accompanied by email notifications.
For instance, when an issue is created/changed/solved, notifications can be sent to all the participants involved in the process: dispatchers will be quickly notified of a new issue, the reporter will be notified in case of any changes. A person responsible for the issue solving will be informed that they are required to make an action on their part.
5050 Solman API :: Notify All Partners, Both Users and Partner Organizations
Email notification can be sent to different types of business partners: users and/or organizations.
Solman API functionality allows getting an email and a full name both for a user and an organization through some central person:
5051 Solman API :: Get Incident Texts according to User Authorization
To separate different participants’ roles in the process, standard authorization can be used. Standard authorization for texts display can be considered in order to determine the information that should be displayed for different participants of the process.
For instance, when the configuration option is switched on:
An email for Business users (the Reporter’s role) will contain standard texts approved for them by authorization (for example Description and Reply). The Support Team members (the Processor’s role) will receive emails with internal notes and other texts approved for them by relevant authorization:
When the option is switched on, the email notification contains both Old and New values for a changed parameter:
5053 Solman API :: Notification Email Has Incident Information Completeness Close to That in Web Interface
In order to avoid having to use both notification emails and login to the ITSM system, notifications contain information necessary to fully understand the subject of the issue or changes in it.
All the elements of the email notification content are fully configurable and may be disabled.
5094 Solman API :: Inbound Processing :: Incident Update from Email
An issue in ITSM can be updated via email. There is no need to login to the system.
Just send an email: mention the issue number in the subject (or reply to the notification) and additional description/attachments from email will update the existing issue.
The status of the issue could also be switched to “In Process” in case additional description or request is added to the existing issue by the reporter via email.
Actions can be captured from the email, just press an appropriate button in the notification mail:
Now it is not only a transaction type which can be defined automatically, but also a category level.
The main purpose for the current feature is to define a unique category level based on the recipient’s email address.
5159 Solman API :: User SU3 Settings
The current feature provides SU3 parameters to control user activities in ITSM.
The set of user parameters is described below.
- /SKYBFR/NO_EMAIL. Value X – no emails from ITSM.
- /SKYBFR/REPORTER_REP. Value X – emails to reporter reply only.
- /SKYBFR/PROC_TYPE. Value ZMIN – emails only for the selected transaction types.
- /SKYBFR/PRIORITY. Value HIGH – emails only for the selected priority.
- /SKYBFR/SOLD_TO_ID. Value for the Business Partner ID – emails come only from reporters from the defined companies.
5167 Solman API :: Action Buttons in Notification Email Dependent on Current Incident Status
The action buttons in the email notification should be dependent on the Incident’s current status. For this purpose, the custom table /SKYBFR/YCA1C_SR is developed.
5185 Solman API :: Template Users’ Authorization Check
Organizations in the SAP system have Business Partner ID, but do not require any user ID. Consequently, there is no possibility to assign business roles in order to control user authorization. This feature allows assigning business roles to the Organizations’ Business Partners. The main purpose is to provide authorization check for organizations
5196 Solman API :: Catch “Created By” and “Changed By” in CRM Order as User Taken from Sender Email Instead of Technical User
The main purpose of the current feature is to avoid unnamed SMTP_USER in CRM order tables. The underlying idea is to catch Created By and Changed By in CRM order as a user taken from Sender’s Email instead of technical user that proceeds inbound. All the mentioned values can be found in the table CRMD_ORDERADM_H. The fields CREATED BY and CHANGED BY contain real user ID based on the email.
5209 Solman API :: Button to Open Incident Directly in WebUI
Button to Open Incident Directly in WebUI is developed for emails.
After an Incident is created, a notification email is generated. Each email contains the button of “Open in WebUI”. This option allows opening the Incident without following a longer path: log in to the SAP GUI => entering the transaction SM_CRM,…
After an Incident is created via email, IBase is determined automatically. The IBase ID can be verified in WebUI.
5312 Solman API :: Technical User for Allowed Domain of the Reporter
This feature helps to avoid uncontrolled issues creation in the system and not to miss any issue or request from the company’s employees (sent from the host name registered in the system).
For all the employees of the company (even if User and Business Partner are not yet created in the system) issues will be registered on behalf of the technical user defined in the organizational structure of an appropriate company.
This functionality allows secure creating incidents for a certain organization in case of “Sold-to Party Determination” via organizational relationships (Sold-to Party Determination via Reporter’s Org Unit as an Example). Also, it makes it possible to distinguish kinds of authorization for issues processing for every individual Customer via Technical User, linked to the IBase component.
Configuration should be processed for each IBase component individually.
