Termination‑date entries originating from Automation for Jira/Atlassian API or coming from Workday produced queued deactivation events that were investigated and resolved to match root causes observed across tickets. Workday field mapping issues were identified as a cause when only the 'Last day of work' / End Employment Date was set and did not trigger the automation; teams monitored Workday for the authoritative termination field and adjusted scheduled disable actions to 'pending' until the correct termination data propagated. Where automation and portal records showed different exit dates, IT‑Service Portal and Jira records were reconciled so the automation queued the intended date. Expedited requests were handled by administrators marking the disable action pending and performing immediate manual locks when requested; Automation for Jira sometimes retained the original queued date after a manual lock, and tickets were closed with the manual action recorded.

Records that referenced the wrong account (for example selecting an internal user in an external‑provider field) were corrected so Okta automation targeted the correct identity; in cases where the account was already deactivated no further action was required. Propagation or sync delays caused termination dates to be invisible in Okta or other identity systems, and administrators confirmed propagation status in identity logs before taking manual action. When Automation for Jira reported a due date reached but additional human steps remained (hardware returns, vendor‑specific accounts, licensing/AD changes after externalization), technicians manually locked or suspended accounts after reviewing automation logs and due‑date notifications; hardware return instructions or vendor links were provided as documented. Failed delivery of offboarding/hardware‑return emails because of missing or invalid personal addresses was recorded and tickets proceeded to account lock when required; missing approver or manager fields were restored or alternate approvers were engaged so approvals could complete.

Throughout, automation logs and due‑date notifications, identity‑system records (Okta/AD/licensing), and Jira Service Management fields were used to confirm queued events, verify execution, and record manual interventions. It was documented that academic departments (or LCC via Jira Service Management when no academic contact existed) owned exit‑date extensions. Firefox compatibility notes for the corporate offboarding form and device‑specific guidance were communicated when relevant.

Offboardings were executed and reconciled across identity, mail, licensing, asset and ticketing systems and recorded against HR effective dates and scheduled automations. Identity and SSO: Okta and Azure AD/Entra primary and secondary accounts were disabled, suspended or deleted per exit dates; immediate terminations included Azure AD session revocations and Okta session clears where supported. Recurring provisioning jobs that re‑added memberships were identified and removed. Where Okta deactivation did not remove accounts in independently managed or non‑SSO services (examples included Auth0, O'Reilly, 1Password and other third‑party apps), those accounts and memberships were manually revoked or recorded as outstanding; several incidents were noted where Okta disabled linked apps but no further manual deprovisioning was recorded and tickets had been auto‑closed by Automation‑for‑Jira, so technicians rechecked and reopened tickets or logged remediation when gaps were found. Notifications and scheduling: automated deactivation notices and Automation‑for‑Jira due dates were reconciled with real‑time HR requests; technicians annotated or closed duplicate tickets and recorded human‑initiated early disables or delayed actions. Directory retention and mailboxes: account recoverability windows (Azure AD) and mailbox retention (≈90 days default) were tracked and deletions/externalisations logged with restore windows; mailbox auto‑replies, forwarding recipients and delegations were documented and Legal/Data‑Protection approvals were sought for central mailbox redirection. OneDrive and leaver handling: failed leaver‑flow notifications were tracked and affected users were reprocessed through specialist offboarding flows to restore transfers and permissions; files required for ongoing work were moved into shared/team SharePoint sites before deactivation. Endpoint and MDM/Jamf: devices were locked or blocked via MDM/Jamf and stale device records were reconciled after returns; devices signed into personal Apple IDs were marked non‑reusable until signed out or factory‑reset and cases without a managed device record required hardware recovery or legal escalation to enable remote wipe. Hardware returns and logistics: returns were coordinated through the refurbisher/SmartSupport workflow; technicians delivered return instructions, carrier labels and tracking numbers via the external portal or emailed labels to private addresses when corporate lookups failed and logged handover details. A browser compatibility symptom was recorded where the packaging/label web form was not functional in Firefox and technicians advised alternate browsers. License, telephony and externalised accounts: licence blocks, tier mismatches for contingent/external transitions and manual unassignment where group removal did not clear subscriptions were reconciled; telephony numbers and carrier updates were deactivated and externalised accounts with changed usernames/external addresses were created where required to preserve portal access. Student and community systems: learning‑platform and community accounts were suspended or deleted per withdrawal/exit dates and membership removals and HE data updates were recorded. Escalations and approvals: Legal/Data‑Protection were engaged for urgent disables, central mailbox access approvals and communication embargoes; immediate disables for non‑compliant or high‑risk leavers were recorded and any subsequent reactivations requested by HR were documented. Ticketing and audit: actions were logged in tickets including deactivation timestamps, returned‑asset tracking numbers, manual group/owner removals, OneDrive transfer outcomes, password‑reset actions to external addresses, community/Care/MyCampus suspensions and evidence for disputed exit dates and temporary reactivations. Cases where Automation‑for‑Jira auto‑closed tickets or where only SSO deactivation occurred without recorded manual deprovisioning were identified and rechecked; technicians reopened or annotated tickets and documented any remaining remediation.

Returns were processed primarily through the internal asset‑return portal (navigate: Abdeckung → Rückgabe → Auftrag). Agents directed requesters to request packaging materials and return labels via that portal; in practice IT did not proactively dispatch return shipping information as a standard service, and agents only generated or emailed courier labels (for example DHL labels, DHL Express or multi‑barcode formats) when the portal failed, was region‑restricted, or produced incorrect labels. When corporate mailboxes were inactive, labels and packaging instructions were resent to employees’ private email addresses and tracking was recorded in Inventory360/MEA to close tickets. Drop‑off at regional IT sites (Berlin, Campus Nuremberg) or on‑site wipes (Munich) were offered when shipments could not be created due to missing dimensions/weights or other metadata; when package counts/weights were unavailable, agents requested per‑package weights or used the New Hires shipping profile as a documented fallback to create shipments.

Browser compatibility and guidance: agents documented a recurring Firefox incompatibility with the returns form and used alternate submission channels (Google Forms, SmartSupport/SmartSupport GmbH, Conbato or other vendor portals) when the portal was inaccessible.

Apple devices and Activation Lock: agents advised that company iPhones/iPads required the user’s Apple ID to be signed out and activation lock cleared (Apple support article https://support.apple.com/en‑us/109511 was referenced). Returned devices that still presented Activation Lock were typically recorded as scrap unless documented recovery existed (reachable Apple ID credentials, recorded passcode reset, or HR‑approved authorization). Endpoint/MDM teams collected IMEI/serial numbers, looked up devices in Jamf/Apple Business Manager and attempted remote wipes only after device serial numbers and HR authorization per termination agreements. Devices still enrolled in ABM/Jamf or missing IMEI/serial links in MDM were recorded as reprovisioning‑blocked; Macs were removed from management and erased when conversion or reprovisioning required it and manager approval was recorded when removing management to convert devices to personal use.

Escalation, tracking and ownership transfers: lookups in Inventory360, Jamf/ABM, SmartSupport and HR/Workday resolved missing assignment or contact data and identity was verified with HR when records conflicted. Offboarding and account‑suspension workflows were monitored across Inventory360/MEA, Salesforce, CARE, OTKA and telephony systems and Jira automation rules were watched for prematurely auto‑closed offboarding tasks. Vendor delays, incorrect packaging, return emails in spam, and unresponsive refurbishers were escalated to managers and alternate courier or third‑party handling was arranged. When employees sought to keep or accept company hardware, IT accepted transfers only after HR provided a hardware‑takeover letter or equivalent authorization; IT did not draft legal takeover documents. Small devices and accessories found on site were temporarily held by colleagues or secured in server‑room cabinets and missing accessories were logged in asset records.

Impacted automations were restored by either returning ownership to an active account so the owner could sign in and refresh Power Platform connections, or by replacing departing named users with designated service or shared accounts and adding co-owners and alternate recipient addresses. In several incidents a deactivated or blocked account was re-enabled and its license restored so the account owner could reauthenticate and remove the connection error. In other cases flows and connected Forms were updated to use a service account (for example s.auditcompliance@svc.iu-it.org) and to add co-owners and alternate recipients so email-forwarding and notification workflows continued without interruption. Where Forms ownership transfer was required for continuity, Forms were transferred to the supervisor or to a designated shared mailbox (examples: netzwerk.fkb@iu.org, rc_kulturelle_bildung@iu.org) and public Form links were preserved for the requested period so published links remained functional after the employee’s departure. One incident involved a student-provisioned account that had been incorrectly included in offboarding; re-enabling that account and refreshing its connection removed the immediate errors.

Access-removal requests for OpenAI/ChatGPT IU Org or other model playgrounds were handled by application-level administrators or via central identity/identity-management depending on administrative control. When users reported unreliable or failing self-removal from OpenAI/ChatGPT organizations, administrators performed org-level removal to revoke access. Where application teams had direct admin control, accounts were removed or disabled on the requested effective date and the action was recorded; when teams lacked control, users were directed to the application owner or asked to create a Jira Service Management request and the application team completed the removal. Central account deactivation in the identity/identity-management system was used where applicable to revoke access across systems. Teams confirmed that access was no longer possible before marking tickets resolved. Tickets were subject to automatic closure by Automation for Jira after configured inactivity periods.

Offboarding reconciliations combined identity deactivation verification with physical asset intake and inventory reconciliation. Accounts for departing users had been disabled in Okta and, where applicable, Azure AD; timing varied (some deactivated on the leave date, others after hardware receipt) and manager or HR confirmations were used when timing differed or suspension dates were requested. When hardware returns were required, staff created carrier return labels and tracking, sent labels/return links to departing employees or designated contacts (corporate or private email when Workday contact data was unreliable), and issued multiple labels when multiple packages were expected. Returned items were accepted via carrier delivery or local hand‑in at staffed reception or IT locations and logged in the inventory system (Inventory360 or equivalent). Where sites were unstaffed, staff arranged presence or routed devices into the refurbisher/Smart Support workflow; returns from unstaffed locations were only accepted when staff arranged shipment to the refurbisher or Smart Support. Devices that had been issued but never put into use were processed back into inventory and routed to Smart Support when specified, with asset tags and PO numbers recorded. Devices sent for reuse were wiped or factory‑reset; Windows 11 primary‑user‑bound units were imaged/fresh‑started during reprovisioning. Offsite refurbisher/Smart Support receipts and tracking were used and units were functionally tested on arrival. When the corporate hardware return web form was incompatible with a browser or when no formal hand‑in ticket existed, staff recorded hand‑ins manually or via alternate intake; device‑management telemetry (JAMF last check‑in timestamps, Windows last‑logon/hardware scan times) and Jira automation due‑date indicators were used as corroborating evidence of return. Discrepancies — missing, delayed or unusable tracking, devices still showing as 'productive', wrong reported locations, duplicate shipments, or items later found locked away — were reconciled by checking local IT hand‑in receipts, inventory history and MEA/asset records, procurement and shipment logs (POs, asset tags, serial numbers), device activation/service history, refurbisher/Smart Support tracking and reception records, and access‑control logs. Duplicate or multiple MEA/asset entries were investigated by matching asset tags and serial numbers to physical devices and consolidating or retiring redundant records. Incidents with inaccessible tracking or evidence of loss/theft were treated as potential loss events and assets were reclassified or retired in inventory with refurbisher, procurement and HR involved for disposition. Tickets were closed after hardware arrival was logged in inventory and account deactivation status in the relevant identity systems was confirmed; however, some tickets recorded hardware return without documenting cloud resource access or account deactivation (for example SharePoint file access), creating an audit/documentation gap that required follow‑up with HR or the access team. Returned asset types explicitly recorded included laptops, monitors, keyboards, mice, headsets (Polycom Blackwire, Jabra models), iPads and Apple Pencil/cases/screen protectors, laptop sleeves, docks, phones, access cards and authentication tokens such as YubiKeys and Kentix tokens, with asset tags or serial numbers logged where available.

Support reviewed the request and confirmed they did not hold or have access to Arbeitsbescheinigungen or other personnel records and were not the authorized issuer or transmitter. Support informed the requester that HR was the responsible contact and directed them to HR so HR could provide the required Arbeitsbescheinigung and, if needed, transmit it electronically to the Bundesagentur/Agentur für Arbeit, issue written confirmation of transmission, and mail remaining documents. The ticket was closed after redirecting the requester to HR.

Support prepared the Okta workflow link and provided the Okta user profile link plus a renaming checklist to the requestor, then scheduled a Teams meeting to coordinate execution. The rename was staged to run only after the user's new MacBook arrival to prevent device-side complications; the Okta workflow was used as the execution mechanism and no errors were reported when prepared.

The account was removed from the institution's Azure AD tenant by that tenant's administrator and the associated Microsoft 365 licenses were revoked in Azure AD. After the tenant-level removal and license cleanup the account no longer appeared as a member of the external organization and the user could sign out of the wrong org and sign in to the correct tenant in Teams.

The account was locked/disabled in the identity system and the user was removed from configured distribution lists and collaboration groups (e.g., Teams). Where appropriate, an Exchange mailbox forwarding rule was configured to redirect incoming mail to the nominated recipient. In cases where no server-side forwarding was found and the mailbox could not be deleted, the user's license was removed so the mailbox no longer accepted inbound mail, which stopped further forwarded deliveries (example: Deskbird reminders).