Before opening an incident with Product Support
Before you open a Support Incident, there are several steps you are expected to perform yourself before engaging with Product Support. Most issues encountered during an implementation are either Configuration or Permission related issues and do not require Product Support engagement to resolve them. Some of the more common reasons for running into issues are due to Best Practices not being followed, Implementation Steps have been skipped, or you are trying to get the system to do something that is not functionally supported (If its not in the Handbook, then its not Best Practice). The below diagram indicates what steps you should perform first before you open a Support Incident:
You are encountering an Application Error, undesired UI behaviour or a permission related issue and are unsure as to what may be the cause. Your next step is to try and understand the issue better and conduct certain checks before engaging with Product Support by following this process flow. Start by understanding the scope of the issue
- Is it impacting a UI or particular data/rating/function on Sucession Org Chart or at any other location
- Is it impacting multiple users or a single user
- Has the issue occurred after making a configuration change or enabling a feature?
Handbook & Configuration Checked
It is wise to double check your configuration based on the related Implementation Handbook and the stage of the implementatin you are at (base configuration, feature configuration, data imports, etc). There are several questions you can ask yourself to help identify the possible cause -:
General Configuration - Please be sure that before you open a support incident with Product Support, you have performed the following sanity checks on your configuration/permission - bearing in mind most issues are due to configuration issues
- Rating issue on Succession Org Chart - Check the source of the rating showing on Succession Org Chart and filter option selected for the same.
- Succession nomination issue: Check the required permission in RBP and make sure to check the target population. In MDF Position nomination method, Succession Planning permission & Succession Management & Matrix Report permission depend on POSITION object therefore make sure that target population is correctly configured.
- Performance-Potential matrix: Make sure that PROCESS is correctly set and filter options are correcly configured when generating the report.
- Check that the fields permission/configuration is correct, according to the Succession implementation handbook. If the field is hidden in data model xml then even after giving read permission in RBP, the field will not show in the instance.
- Has the configuration changed recently?
- Can the recent change be un-done?
- Can the issue be reproduced for just 1 or multiple users?
- If the issue is reproducible for all it is still likely to be a configuration issue.
- If it seems to be related to 1 or a small user population - the next step is to check and verify that the data is correct.
Succession Org Chart xml
Make sure that the fields in Org Chart xml is correctly configured, as per the configuration given in handbook, the picklist mapped to the fields must have the correct/same value as present in the picklist file.
Tips & Tricks KBA Checked
After confirming that the configuration is correct as per the definition in the related Implementation Handbook, you should next consult the Tips & Tricks FAQ article related to the Module/Area/Feature in which you encounter the issue. You may find that someone else has encountered the issue before and that a knowledge article exists on how to resolve the issue without needing to engage with Product Support. It is imperative not just for Product Support, but also you the Implementation Specialist, to ensure that we rule out all possible causes first before engaging with Product Support. The below article is only the top level, and breaks down into specific topic/feature guidance.
2340971: Succession Implementation tips & tricks from Support
Support Incident Created
Each Tips & Tricks article ends with a list of information that would ensure quick review and possibly resolution of the issue you are reporting. Please check individual Tips & Tricks articles if you are unsure what information to provide when reporting issues related to that Function/Feature. Below you will find clear explanations of engaging with product Support and some of the common terms used by Product Support when providing responses.
- Incident Priority
- Creating Support Incidents
- Interim work-arounds
- Product Defects
- Configuration Changes
- Enhancement Requests
Please choose a priority correctly. The below article helps to give an idea of what types of issues would qualify for certain priorities. It is important not to abuse incident priority, as this will have wider impacts to supporting you and your implementation.
2155738: Incident Prioritization for Succession
Creating Support Incidents
When creating a Support Incident, there are some considerations you need to take when defining the Priority of the incident, such as -:
- Is my customer live or going live in the next couple or weeks or months?
- What stage of the Implementation is currently being impacted?
- How many users are actually impacted?
- Is there a work-around that can be used in the interim to circumvent the issue and continue the Implementation until a permanent solution can be provided?
- Have I performed due diligence and checked my configuration and/or data to ensure the issue is not caused by something my or I have recently done?
- When did the issue start occurring? (After latest config change roll-out, product release, product patch)
Interim work-arounds are commonly recommended to keep you working whilst Product Support/Development are working to identify a permanent solution. Please do consider using interim work-arounds, as the aim here is to ensure you do not encounter any further delay to implementing the product/feature.
SAP SuccessFactors is a multi-tenant system, meaning all tenants run on the exact same code-base. Meaning it is impossible to patch a fix to a single instance. As all instance are running on the same code-base, when a patch is deployed it is deployed to the data centers on the impacted release which means all customers get the patch/fix at the same time. Patch deployments are always performed during the weekly maintenance window at the end of the working week (starting early on a Saturday morning usually). How does a Defect Fix process work? Well, development will need to -:
- Identify what type of issue it is (Regression, Functional Gap, Enhancement)
- If it is a regression issue, then Development will work to reproduce the issue in the current build they are developing (the next release)
- Develop the code fix for the next release and verify it causes no further issues
- Determine whether the fix can be patched to the current release or whether it requires deep regression testing to ensure no further defects are introduced, meaning it will be fixed only in the next release
- If the fix can be patched to current release, the patch will also have to pass Risk Assessment and QA Testing to ensure it can be safely aplied
- Patches will get their final go/no-go approval by the end of day Thursday every week.
What if the fix cannot be patched?
- Then you will need to wait for the release where it is fixed. If a defect cannot be fixed it is usually due to unacceptable risk involved with patching the fix, as it requires deep QA testing and validation, which cannot be completed as part of a Patch QA testing process.
Can any defect be patched?
- No. Development Engineering will determine the risk and impact a patch would have, or whether a patch is not possible as a more comprehensive fix is required
What about patching Enhancement Requests?
- We do not patch Enhancement Requests - as they require deep regression testing, they will only be deployed during a quarterly release - this is across the board, and no exceptions
What is a Functional Gap?
- This means that what you are trying to do, is not currently support by the application. Meaning the code would need to be developed to handle whatever it is you are trying to do - this would also fall under an Enhancement Request, as the behaviour/functionality never existed, and needs to be created. FunctionGap fixes are treated as Enhancement Requests, therefore they will not be considered for patch either
Please note that Succession Management Product Support generally do not make configuration changes for customers or partners. There are only a few items in which Product Support will help make certain minor changes for Live customers, as a majority of general configuration changes can be made by a system admin via the web UI. Please refer to the following articles to help guide you are your customer on how and which services to engage, depending on the change request
2252666: Supported XML Software Change Request for Succession Org Chart & Succession DataModel- Succession Management
Please do not open a Support Incident if you have identified functional requirements or potential enhancement possibilities for Employee Central (or any other SAP SuccessFactors product). Please follow the below article to understand how to correctly submit an Idea to our Product Management team for review and consideration.
2344294: How to submit an Enhancement Request for SAP Succession Management.
KBA , LOD-SF-SCM , Succession Management , Problem