Investigations combined targeted Workday searches with source-side inspection and reprocessing in Oasis. Support used Workday's 'Find Invoices for Company' search with memo-field filters and reviewed payer transaction histories by date to find items that had been created on student records or moved between student and payer accounts. Where items had been created on student records, the Oasis invoice data was corrected so the Bill‑to‑Customer matched the payer and the records were resent using the integration 'Send to Workday' operation; several cases showed repeated sends had no effect until the bill‑to field was corrected, while other pushes only became visible after allowing time for Workday processing/refresh. When updates (invoice-level changes or PO numbers) did not appear because the invoice was part of a consolidated invoice or because the wrong record level had been pushed, items were reprocessed or re-pushed at the invoice level so Workday records and payer totals reconciled. For ELCAS-related discrepancies, Oasis transaction rows (TRANCR incoming credits, TRANDR debits and JNLFRO journals) were inspected; tracing filing references revealed role-to-role transfers or debits that had balanced off TRANCR credits, and the originating allocations or transfers were corrected and affected credit notes or invoice lines were reissued or reallocated so net balances matched Workday. The investigation also identified a behaviour-by-design case where an expected payer discount did not appear in Workday because Oasis had allocated the invoice to a credit note (PADISX), which effectively cancelled the payer discount; in those cases no separate discount line was pushed to Workday and the situation was resolved by recognising the allocation outcome and adjusting Oasis allocations or reissuing the appropriate credit/invoice lines so the net positions aligned between systems.

Misapplied voucher and lingering refund line items were resolved using Workday Payment Refunds and by reconciling upstream source transactions. For misapplied vouchers, a refund of type CORVOU (Correction to Voucher) was created in Workday Payment Refunds, the specific outstanding voucher transaction was selected in the refund list, and the refund was committed; this cleared the original voucher transaction on the incorrect role. For cases where CORREF was applied but extra refund transactions remained, the extra refund line items were identified in the internal/upstream payments system, verified as not having synced to the external finance system (IU’s Finance System), and then balanced off in the source system; after those upstream transactions were balanced, the Workday refund transactions cleared. An attempt to use ONLCOR did not clear the lingering refund transactions in the reported incident, and payments themselves were confirmed already reconciled prior to clearing the refund lines.

Access failures were resolved by different actions depending on root cause. When Workday links produced errors or rejected credentials, launching Workday from the Okta dashboard tile restored access in multiple cases by enforcing SSO. Password-related failures were resolved by admin password resets and by triggering password-reset emails for the Okta identity (including external Okta accounts); when users had set a new password but Workday still rejected credentials, launching via Okta SSO bypassed the rejection in several instances. Browser-specific problems — including missing/garbled UI text or XpressO “Local Date Attribute is missing” traces — were resolved by switching browsers (Chrome/Edge/Firefox/Safari/Comet), testing in private/incognito mode, or clearing corrupted cache and cookies; the Workday authentication gateway URL (https://wd3.myworkday.com/wday/authgwy/iubh/login.htmld) restored access in some cases. Device/onboarding provisioning failures were resolved by re-running the Task Sequence or waiting for account provisioning to propagate (commonly 1–2 days). Session auto-refresh or unexpected tab reloads (noted in Edge and linked to short Workday session timeouts) were handled by advising filing a Workday Support ticket for session-timeout settings and by testing other browsers; no permanent local fix was implemented in the recorded case. Persistent propagation delays, reproducible backend “Workday sign in error” failures, or cases referencing corporate password restrictions were escalated to the Workday team (wd-support@iu.org and regional contacts). Support also restored access after confirming or correcting the email address associated with the Workday app tile in Okta’s app info. Some interruptions proved transient and resolved without user action.

The procurement requisition flow was executed in Workday by creating a requisition event and routing it through the normal approval chain; once approvals completed a PO was generated and sent to the vendor contact. When updated PO numbers from Oasis did not appear on Workday invoices, it was observed that pushing the payer record did not update an invoice's PO fields and that Workday refused updates for invoices that had been included in consolidated invoices. In those cases the underlying invoice record needed to be reprocessed and the consolidated-invoice state accounted for before the updated PO appeared on the invoice. Additionally, invoice approval routing was independent of internal ticketing: a Jira approval was used internally to indicate authorization to order but did not auto-approve the Workday invoice. In one instance an approver who had not previously handled hardware approvals received the Workday approval request; after confirming with the ordering contact via Teams the approver completed the Workday approval (cost center and justification fields were present on the invoice).

The immediate symptom was avoided by using keyboard focus rather than clicking the dropdown: the user tabbed to the cost-center field and typed the cost-center code (for example CC21405) which allowed the manually entered code to be selected. Support also noted browser differences as a contributing factor and suggested testing alternate browsers as part of troubleshooting.

The user paid the FedEx customs invoice personally and submitted the receipt as an expense claim in Workday. The expense claim used a memo/notes entry of 'Zollgebühren' (customs fees) to identify the cost type; no institution-side direct-pay arrangement or specific cost center was supplied in the ticket.

Support confirmed the IU account was inactive, accepted the user-provided alternative addresses, and sent the required information to the alternative private email. The correct private email for the user was recorded as stefkaspiegel@icloud.com with an alternative stefka.spiegel@gmail.com noted for delivery.

Display-name and approval-routing issues were resolved by correcting authoritative fields in Workday and allowing the HR/profile synchronization to propagate. For display-name problems (job title, academic title/prefix/honorifics) Workday name/title fields were updated in Workday by HR or managers; corrected values later appeared in Microsoft/Azure/Office365 profiles, SharePoint, Okta, Teams, Zoom and other downstream displays after the regular sync completed. For approval-routing and cost-center problems, approver roles and cost-center ownership were reassigned in Workday (replacing predecessors) and Automation-for-Jira/Jira workflows were confirmed to read Workday 'Approver' and cost-center approver assignments (not only the Manager field); changes propagated to approval automation and SelfService rejections tied to stale cost-center assignments were cleared once the Workday cost-center record was corrected. Where downstream systems relied on EmployeeID, missing BI or competency records were restored after the Workday employee-number was corrected to match downstream mappings. Investigations also found cases where required columns were absent from the upstream Workday report/REST feed (example: ManagerID and Management Level were not present in the Workday report that populated the Dataverse table crfc0_Workday_Data_Warehouse_Academic_Staff), preventing the Dataverse table and dependent Power Automate flows from being populated by the existing sync; the issue was traced to the source report rather than the Dataverse pipeline, and the documented remediation was to expose those attributes in the Workday report or change the integration feed so the downstream table could be populated. In workflows without direct Workday integration (example: some Competency App scenarios), non-integrated mitigations such as UI warnings were used. Change requests and report/field additions were routed through Workday Support or HR contacts (wd-support@careerpartner.eu or hr@iu.org as appropriate). Propagation timing varied by target system and approval flows: typical synchronization completed within 1–3 days, while changes requiring manager approval or traversing slower connectors could take up to two weeks.

An Adobe Sign ↔ Workday integration quick-start guide (Adobe helpx Workday integration documentation) was provided as an example that matched the requester's needs. The internal Adobe Sign administrator was identified (Tanja Wulfes) and shared with the requester. The requester confirmed the provided documentation and admin contact met their requirements.

Support consistently documented that Workday administration, provisioning, and authentication were not managed by the IT team and that most issues required escalation to the organisation’s Workday support channels (examples: wd-support, wd-support@iu.org, Workday Competence Center). Specific actions and findings across matched tickets included:

Tickets were closed after routing to the appropriate Workday or application support channel, after Workday restored access or applied requested role changes, or after confirmation from the requester that the issue was resolved. Agents consistently preserved error text, screenshots, affected-user lists, and exact role names in the ticket to aid Workday or third-party support triage.

IT verified that the supplier emails were being delivered to invoice@iu.org, so mail delivery was ruled out as the cause. The user was instructed to open a Workday Support ticket (using the Workday Support ticket template rather than a plain email); a Workday Support template link was provided in the ticket. The incident was escalated to Workday Support for investigation of the Ascend import process and the IT ticket was closed after guidance was given.

Investigators examined the Oasis→Workday integration, found larger-than-normal processing queues resulting from an integration issue the previous day, and processed/cleared those queues. After the backlog was cleared the integration returned to normal operation and contact changes began appearing in Workday within a couple of minutes. It was also confirmed that there was no simple way to bulk-import contacts from Sage into Oasis.

Support staff confirmed these issues were related to the Workday absence/leave system rather than the campus IT platform. Cases were routed back to the requester’s manager for approval and business-process verification; when the issue fell outside managerial handling, staff provided the Workday Support contact (wd-support@iu.org) for technical investigation. No platform-side fixes were applied within these tickets; screenshots were sometimes attached but no error codes were present. Tickets were closed after manager verification or after awaiting user response when no further information was provided.

The 'enhanced writeback' feature in Okta was enabled in the production environment (the feature had been previously tested in the Okta/Workday test environment). After enabling the feature, the team retried writeback for the affected users and the e-mail writebacks succeeded. Documentation was updated and the stage environment writeback setting was planned to be reverted later as part of operational cleanup.

The ticket was escalated and forwarded to the Academia on Campus deputat-accounting team with the instructor's detailed counts, course identifiers (Forschungsmethoden MMET01-01, Managerial Economics DLBBWME01), dates of exam creation, historical SWS reductions, tutor SWS coverage, and the instructor's proposed SWS allocation for review and adjustment in the deputat accounting system.

The ticket and attached error screenshot were reviewed and the issue was determined to be outside this team's scope (not an Amazon- or Workday-specific support responsibility for this team). The user was advised to contact Procurement or Workday support to investigate the automatic order cancellations and any integration-related errors. The ticket was marked Done/closed after routing guidance was provided.

The incident was investigated and identified as related to a Workday-driven workflow; ownership was escalated to the WCC/Workday team for further investigation and handling. Support marked the Freshdesk ticket done and advised that WCC/Workday colleagues would contact the requester to resolve the merged-message outcome.

The user completed the purchase by following a different, undocumented procedure and the ticket was closed without detailed reproduction steps. The service was noted to likely require a Deutsche Bahn account and not be managed by IT; support directed that HR or the service owner should be contacted for further assistance if ordering problems recurred.