Reproducing the Issue
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 Data 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 Process Blocker, 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 field/portlet/function
- 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/data - bearing in mind most issues are due to configuration issues
- Business Rules - Remove any rules assigned to the element/field and test again
- Check that the fields configuration is correct, according to the Employee Central Master implementation handbook. If the field is a picklist or Object related field, ensure that the related picklist/object is configured correctly (double check the configuration / compare it to a working one).
- 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.
Element/Field Configuration - It is always best practice to check and verify that the field you have enabled for a particular hris-element is valid for that element. Please refer to the "Data Object Tables" handbook under the section "Reference Information" which details what fields are supported, and how the field should be configured. Some of the more common issues encountered are due to trying to re-purpose delivered fields to do something else. Please note - the following is a list of things you should not do when configuring fields
- Do not configure a pre-delivered field to use a custom picklist > Always use the exact picklist that has been delivered. If the customer has other requirements - use a custom field instead
- Do not configure an Object field to use a picklist - for example do not add a picklist to the field "company" in the jobInfo hris-element - this is not supported and not best practice
- Do not change an existing field from String to Picklist/Object or Vice Versa - this will lead to Data Inconsistency and possibly even unexpected behaviour - for example you are capturing data in custom-string16 with a picklist assigned to the field, and you decide to change approach and turn the field into an Object field - the best practice is always to use a new custom-string field for the new approach - do not recycle fields, ever.
- Do not delete fields from the XML to "tidy it up" - use the visibility="none" switch to turn the field off - Deleting the field from the XML does not disable the field - potentially it will still show in the UI/RBP/etc. Also when it comes to future configurations, you dont want to accidentally re-use a field that was once a picklist, but now is an Object field. This would again lead to Data Inconsistency and potentially unexpected behaviour
Business Rules - A lot of common issues are due to incorrectly configured Business Rules, which can cause undesired behaviour or even application errors if not created/configured correctly. Typically if a rules is causing an error message -
- Configuration: The rule is not configured correctly - 2277956
- Trigger: Has the wrong Base Object defined for the HRIS Element the rule has been assigned to - 2163077
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.
- 2315109 - Employee Central 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.
- 2155223 - Incident Prioritization for Employee Central
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)
- Will this impact Payroll?
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 Employee Central 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
- Configuration Changes - Scope of Product Support for Employee Central
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. Enhancements Requests are not tracked by support, therefore any incidents raised for enhancements request are beyond the scope of Cloud Product Support.
- 2090228 - How to submit enhancement requests for SAP SuccessFactors products
KBA , LOD-SF-EC , Employee Central , How To