Troubleshooting Absence Management (AESOP) Integration
Issue: AESOP absence is not reflecting the correct ESS (USPS) position when the absence is pulled into ESS.
Listed below are the chain of events that take place to make this determination:
When ESS pulls in the absence, it will first look to see if there is a (USPS) position # in the ‘Employee External ID 1’ in the employee’s AESOP employee record. If there is, it will apply the absence to that position # in ESS.
If ‘Employee External ID 1’ is blank in AESOP, ESS will then look at the AESOP school building (IRN) assigned to the employee’s absence and will apply the absence to the first position it encounters for the employee containing that building IRN in ESS (whether it’s active or inactive, non-archived or archived position) .
If there is no building IRN tied to that position in (USPS) ESS, ESS will apply the absence to the #1 (USPS) position (active or inactive, non-archived or archived) for that employee in ESS.
To resolve the issue, enter the USPS position number in the user’s employee record in AESOP.
Only employees who are having an issue with the AESOP absence being applied to an incorrect position should be corrected by entering the position # in the ‘Employee External ID 1’ of the AESOP employee record. ESS-995 will improve the behavior on how the AESOP absences are being applied to the position in ESS.
What if the employee has a new position in USPS that is eligible for leave? Does the Employee External ID 1 in AESOP need to be updated with the new position number?
Yes, if that is the only position eligible for leave, you need to update the ‘Employee External ID 1’ field in their AESOP employee record so that the absence pulled from AESOP will reference the correct USPS position.
What if the employee has more than one position in USPS that is eligible for leave? Is there a way to add more than one position number in the Employee External ID 1 field in AESOP, correct?
No there is not. If there are multiple buildings assigned to their employee record in AESOP and they can create absences for any of these buildings and do not want to restrict their AESOP absences to one position (in USPS), they will leave the ‘Employee External ID 1’ field blank in the AESOP employee record. Instead,
When creating the absence in AESOP, they are required to select a building(s). If all USPS positions have the same building (IRN), it will apply the absence to the first position it encounters for the employee containing that building IRN in ESS (whether it’s active or inactive, non-archived or archived position) .
When creating the absence in AESOP, if they select more than one building to charge the absence to (morning in building A and afternoon in building B), if the USPS position have the same building IRNs, it will apply the absence to the first position it encounters containing that building IRN in ESS (whether it’s active or inactive, non-archived or archived position). So in this case, it will create two leave requests in ESS, one for the AM for the position tied to building A and one for the PM for the position tied to Building B.
Issue: In comparing AESOP created absences to ESS leave requests, we are missing AESOP absences in ESS. Why didn’t the AESOP absences pull into ESS successfully?
Most often the reason is due to a mismatch on the absence leave type (i.e., sick, personal), School (i.e., building/IRN) or specific employee data (i.e., Employee ID) between the two applications. To help narrow down the reason, refer to the Data Import View>Absence Create grid (filter row) and query the AESOP absence that did not pull into ESS. You may find that filtering by employee ID, date or processed message ‘error’ may help narrow down your search. View the details of the record selected.
Locate the ‘processed message’ field for a possible error message. For example, “Error creating leave request with conf #xxxxxxxxx;School not found.” Other error messages may state an error found on the employee or leave type category.
Based on the error message, review the synced data grids to confirm there is a mismatch. For example, if the error states ‘school not found’, review the Synced Data View>School grid to determine if there is a mismatch on a particular building in AESOP vs ESS (USPS). If the school grid confirms there is a mismatch between the two buildings ('Is Matched' column denoted with an X), you will need to determine which application has the correct building code (IRN) and make the necessary corrections. (In AESOP, ensure the Master Data>School>General Information ‘External Number’ matches the ESS Building Code’s Building IRN in ESS (USPS). The numbers must be identical (leading zeroes need to be accounted for). If an update is made in USPS, the position sync in ESS must be performed. (ESS schools are linked through the USPS Building Code>Building IRN property, which is synced to ESS when a position is synced).
Once corrected, the next scheduled pull of AESOP absences into ESS, the Is Matched notation X on the School grid should change to a (and the ESS Building Code, Building IRN and USPS Description should populate on the grid) and the AESOP absence should pull into ESS successfully.
Listed below are some of other common ‘Processed Message’ errors:
‘Error creating leave request with conf #xxxxxxxxxxx;Reason not found’.
Review the Synced Data View>Absence Reason grid to determine if there is a mismatch on a particular leave category (or sub category) type in AESOP vs ESS. If the absence reason grid confirms there is a mismatch ('Is Matched' column denoted with an X), review the AESOP Absence Reason ID and if there is an subcategory, the Absence Reason Id2, and ensure ESS has a matching leave type category and sub category.
Once corrected, the next scheduled pull of AESOP absences into ESS, the Is Matched notation X on the Absence Reason grid should change to a (and the ESS Sub Category Status, ESS Sub Category and ESS Sub Category Description should populate on the grid) and the AESOP absence should pull into ESS successfully.
'Error creating leave request with conf #xxxxxxxxx;Employee not found'
Review the Synced Data View>Employee grid to determine if there is a mismatch on a particular employee in AESOP vs ESS. If the employee grid confirms there is a mismatch ('Is Matched' column denoted with an X), review the AESOP Employee Record and confirm the same employee is in USPS, ESS and the employee identification number matches.
Once both applications have matching employee information, the next scheduled pull of AESOP employees into ESS, the Is Matched notation X on the Employee grid should change to a (and all information will be noted in green text) and the AESOP absence should pull into ESS successfully.
‘Error creating leave request with conf #xxxxxxxxx;No Leave data found for Employee’.
This may indicate that employee’s leave data has not been synced with ESS. If you sync the leave balances and it still doesn’t resolve the issue, please ensure leave balances exist in USPS for the employee. Even if the employee may not be eligible for leave, it is a requirement that leave information must exist for the employee in ESS. If there are no leave balances for the employee in USPS, using Core>Leaves-New, create the default leaves with 0 balances. Once the (template) leave balances exist in USPS, re-sync leave balances in ESS
Once both applications are now set up with leave balance data, the next scheduled pull of AESOP employees into ESS, the Is Matched notation X on the Employee grid should change to a (and all information will be noted in green text) and the AESOP absence should pull into ESS successfully.
Please refer to the Synced Absence Management Data documentation for more information on ‘Is Matched’ for Absence Reasons, School and the Employee grids.
NOTE: Outstanding Jira issues to improve the way the AESOP data is being pulled as well as Employee Sync Grid improvements: ESS-995; ESS-996; ESS-1000