Based on the EE Group, only a certain number of appointments can have the same appointment number and appear on the same Appointment Notification. If more than the allowed appointments are created under the same appointment number, then the appointment notification will not display all the appointments on one appointment notification.

CHART:  EE Group and Number of Appointments that can have the SAME Appointment Number and appear on the SAME Appointment Notification

The Appointment Notification will fail to display an end date if the incorrect date field is completed and approved.

If the Appointment Notification has been changed mid process from a Lab to a Lecture, then the Appointment Notification will not print the correct information. To resolve this, the appointment must be fully canceled and then resubmitted.

Unfortunately, once multiple appointments are submitted with the same appointment number they cannot be separated. The only way to separate the appointments is to request CMS to delete the data from the TAE Staging, History, and Letter tables. A ServiceNow ticket will need to be submitted with the following information:

• CHRS ID
• Empl Record Number
• Department ID
• EE Group
• Appointment Number

When this occurs, user will be need follow the “~Manual Load to Job” process:

1. Manually enter the transaction into Job Data, based on the information on the My Approvals page.
2. Return to the My Approvals page, select “~Manual Load to Job” in the Other Action field, check the “Approve” box and click “Save & Submit”.
3. The transaction will no longer appear on the My Approval page.

If the employee you tried to Load to Job, does not appear on the Successful Load to Job Report or the Load to Job Error Report, confirm the following before submitting a ServiceNow Ticket:

1. The Action/Reason is correct.
2. The Eff Seq is not 1 or more without an Eff Seq of 0 being loaded at the same time. (Note: DO NOT change the Eff Seq to 0 unless the row that has Eff Seq 0 is changed first.)

An appointment may fail to load for various reasons. Review these messages to identify the potential cause.

This issue can arise for several reasons. Start by checking if you can locate the appointment. Based on your findings, one of the factors listed below may help explain the situation. Before submitting a ServiceNow ticket, please confirm the following:

If certain fields (Term, Session, Appt Type, Eff Dt, End Dt, etc.) do not match exactly what was entered for the original transaction that was loaded to job, the Cancel After Loaded to Job process will not work. When certain fields do not match what was originally entered for the transaction, the module treats the cancelation as if it is a Mid-Process Cancel rather than a Cancel After Loaded to Job. Using the TAE Approval History page review the original transaction submitted and the transaction submitted as a Cancel.

• If the certain fields (Term, Session, Appt Type, Eff Dt, End Dt, etc.) are different, the transaction will need to be submitted again with the fields matching.
• If all the field are matching a ServiceNow ticket will need to be submitted with the following information:
  • CHRS ID
  • Empl Record Number
  • EE Group
  • Details of the Original Appointment from the TAE Approval History page review
  • Details of the Canceled Appointment from the TAE Approval History page review

When “No Change” is in the Other Action field, the transaction does not load to job and will fall off the My Approval page once the Appointment Notification has been sent.

This could occur for various reasons. Begin by confirming the following items below. If any of the reasons for the notification was NOT generating, the reports NOT appearing and the transaction NOT loading to Job and disappearing, are listed below, will need to submit the transaction again.

1. On the WorkFlow Approvers page, confirm that the user who approved the transaction has access to the Final Load to Job step.
2. On the Workflow Steps page, confirm that the workflow is set up correctly for the transaction being submitted. You will want to confirm that the workflow has the Load to Job and Send Appt Notif box checked at one of the steps.
3. On the User Profile page, confirm the user has the CHR_PT_PeopleSoft_Advance role.

If after reviewing, it is found that the reason for the notification was NOT generating, the reports NOT appearing and the transaction NOT loading to Job and disappearing, is not listed above submit a ServiceNow ticket. The ServiceNow ticket will need to be submitted with the following information:

1. Details of the Original Appointment (CHRS ID, Empl Record Number, EE Group)
2. Details of Final Approver (CHRS ID, Campus ID, Approval Workflow access)
3. Image of the Workflow Steps
4. Details of the appointment from the TAE Approval History page review

On the Appointment Data Entry page, normally this should be entered as appointment type 020 (AE – 16th WTU), however the module does not have this capability. Therefore the appointment must be entered using type 021 (lump sum) to process the additional WTU as a lump sum.

On the Appointment Data Entry page, normally this should be entered as appointment type 020 (AE – 16th WTU), however the module does not have this capability. Therefore the appointment must be entered using type 021 (lump sum) to process the additional WTU as a lump sum.

There are two reasons that this could be occurring:

1. First review the Session Code table and confirm that a Session Code has not created starting with a zero. If a Session Code has been created, you will need to update this on both the Session Code table and the Term table.
2. Second review the Term table to confirm that the Description and Short Description field only have numbers, letters, and spaces. If the Description and Short Description field have other characters beyond that, you will need to update.

This could be occurring because the Term table has not been setup correctly. The Description and Short Description field on the Term table should only have numbers, letters, and spaces. If the Description and Short Description field have other characters beyond that, you will need to update.

There are two reasons that this could be occurring:

1. First review the Session Code table and confirm that a Session Code has not created starting with a zero. If a Session Code has been created, you will need to update this on both the Session Code table and the Term table.
2. Second review the Term table to confirm that the Description and Short Description field only have numbers, letters, and spaces. If the Description and Short Description field have other characters beyond that, you will need to update.

Users are not able to insert a step in the middle of the workflow as the module does not have that functionality. To add a step to the workflow, users will need to add the step at the end of the workflow and relabel the prior steps. This process is explained through the Update TAE Approval Workflows Job Aid

1. If you set up your workflow by EE Group and job code, you need to search by EE Group and job code on the Workflow Approvers page.
2. If you set up your workflow by EE Group, job code and department, you need to search by EE Group, job code and department on the Workflow Approvers page.
3. If you setup your workflow by EE Group and department, you need to search by EE Group and department on the Workflow Approvers page.
4. If you recently inactivated a workflow and did not create a new Workflow with a higher month than the recently inactivated, then the new workflow step will not appear on the WorkFlow Approvers page.

If you setup your workflow by EE Group and job code, you need to setup the hidden fields by the same EE Groups and job codes. Otherwise, the fields will remain visible to the approver.

When "Auto-Change by Position Nbr" is selected if more than one incumbent shares the position number the most recently added incumbent will pull. You will need to uncheck the "Auto-Change by Position Nbr" field so that the approver does not update.

This issue can occur for several reasons. Before submitting a ServiceNow ticket, verify that you have the correct role (CHR_TF_Appr_Auth_Error_Log) and check that the email was not filtered into your spam folder.