Authentication failures during macOS OOBE and first-time app logins were traced to several distinct causes and resolved according to each root cause. Causes and outcomes included:

Technicians resolved repeated bulk and scheduled external/contingent (.ext and Azure AD/B2B guest) provisioning failures by creating and managing accounts through vendor/provider APIs and IU identity/provisioning tools rather than relying solely on spreadsheet bulk imports. Accounts were created with explicit start and term dates so welcome/password‑creation links were generated and delivered to the recorded private email on the correct date; when vendor systems required scoped access, accounts were created with limited scopes and app access was granted through the provider. When activation/password tokens were expired, bounced, quarantined, unusable, or delivered to the wrong address, technicians regenerated Microsoft 365 password‑creation tokens via admin support, resent tokens to alternate verified private addresses, used vendor “forgot password” flows or vendor support when admin resets were rejected, or placed credentials on the IU secrets platform for collaborators without IU‑hosted email. Technicians verified tenant account and license assignment when users reported account‑not‑found or first‑login errors and requested screenshots or alternate sign‑in checks (for example mail.iu.org) to diagnose Microsoft‑account vs tenant sign‑in issues. Okta welcome‑mail failures that prevented password creation were treated as activation‑token failures and triaged alongside other activation‑email issues; user‑side diagnostics (clearing browser cache/cookies, incognito testing) were used when interfaces failed to display expected UI elements. Directory/import errors (firstname/lastname swaps, duplicate or ignored rows, username/email mismatches) were corrected in the authoritative HR/onboarding record or via provider APIs; duplicate or automation‑created erroneous user records were removed and reprovisioned through the correct channel. Approval and contract‑metadata failures were traced to incorrect approver mappings, missing cost‑centre/manager/start‑date fields, duplicate ticket submissions, or lead‑time mismatches; technicians corrected mappings and notification/CC addresses, applied manual approvals or recorded exceptions when source changes lagged, and merged or removed duplicate requests/accounts created by double submissions. Temporary A1 licenses or manual fixes were applied when automation inputs were missing so access was available on start date. Workday↔Okta SSO failures were resolved by ensuring contingent workers were enabled and visible in Okta and by aligning Workday usernames with Okta SSO usernames; problematic import rows were ignored or replaced. Okta and Microsoft 365 last‑login and activation state were used as diagnostic signals to prioritise credential delivery and identify non‑activated users. LMS/MyCampus enrolment gaps caused by missing course/group syncs were handled by restoring or manually assigning the missing membership when automatic syncs had not populated. Atlassian Cloud membership and license propagation delays were monitored and, when automatic membership did not propagate, accounts were added manually to Confluence spaces and Jira projects. Tracking practices captured source spreadsheets as canonical lists and created individual Jira sub‑tasks per external worker to track internalisation, group membership, credential delivery, and verification status; misrouted requests were redirected to the correct external‑user onboarding portal and reprocessed via the proper flow. Where automation‑recorded private emails were incorrect or flagged as suspicious (for example apparent copy/paste errors), technicians verified and corrected the private email with the requester before relying on scheduled token delivery and recorded the verification in the ticket/subtask; tickets that had been closed without documented verification were reprocessed and the corrected contact recorded. Technicians also recorded recurring process constraints observed during provisioning (for example per‑person submission requirements on the freelancer form and missing hardware fields) and documented outcomes in Jira subtasks so activation and credential delivery status was confirmed at ticket closure.

Support restored onboarding and mailbox access by reconciling identity records across Okta, Azure AD/Workday (including AMOS/Workday provisioning) and Microsoft 365, and by completing downstream provisioning tasks. Technicians retriggered or resent activation/verification/password‑reset messages or codes when activation emails or one‑time links were missing, expired, or delivered to alternate addresses; they observed some admin‑initiated password resets did not clear an outstanding activation/MFA prompt. Where Okta was reachable only from a particular device or browser, reachable authenticators (for example Microsoft Authenticator on a personal phone) were used to finish activation and MFA. Technicians provided onboarding instructions for adding an additional MFA factor and recommended using TOTP generators (Okta Verify or TOTP‑compatible apps such as Google Authenticator or FreeOTP) for maximum compatibility; they also noted Windows Hello and Touch ID methods only worked on the device where they were enrolled and that YubiKey/FIDO2 had compatibility limits in some flows. When Workday/AMOS provisioning had not run or extension attributes had not propagated, support corrected identity profiles, set required extension attributes (ea1–ea4 as applicable), created Microsoft 365/student accounts or application assignments directly, provisioned mailboxes, and delivered credentials via Safe; reassigning Microsoft licenses or Okta application tiles restored downstream access after short propagation delays. For hardware token issues technicians provided setup guidance, reconfigured or replaced tokens, and rebuilt or reinstalled devices when faults prevented enrollment or sign‑in. Technicians also verified and corrected Windows 11 group memberships that blocked local sign‑in or hardware‑token authentication; when devices became BitLocker‑locked after repeated sign‑in attempts they used supplied BitLocker recovery keys to unlock devices and completed in‑person or network‑connected provisioning. Staff noted some admin or remote password resets required the device to be on the corporate/CPG network or VPN so cached Windows credentials and downstream access could update. For Apple/iOS enrollments needing Apple ID changes, technicians created or adjusted a private iCloud email for the Apple ID to enable enrollment. For SSO and SaaS integrations support used reference users/profiles to replicate permissions, performed administrative email verification when SSO reported an email as “not verified,” reassigned or manually provisioned mis‑routed application requests, and reactivated accounts where self‑service flows failed. For Cloudya/telephony onboarding support created Cloudya users, assigned site/extensions and external numbers, and resent activation messages. Persistent tile/provisioning/passkey/MFA, license assignment, or hardware errors were escalated to platform owners. Cases often closed after successful sign‑in was recorded in logs.

Incidents were resolved after missing or incorrect identity attributes, device/computer‑account records, site/location assignments, directory/group records, or HR exports were corrected and vendor propagation windows elapsed. Common remediation actions and observations that restored access included:

Common propagation timings observed: transient failures often cleared after short vendor propagation (~5–10 minutes); profile attribute syncs (for example Workday→Teams) typically propagated in ~1–3 days while some systems required up to one week for full propagation. In many cases a simple retry of first‑login or waiting for propagation succeeded; other cases required explicit activation/creation of the computer account, site assignment, device re‑enrollment, or manual replay of stalled automations.

Intake, ownership and ticketing: Procurement details (POs, approvers, delivery addresses, serial numbers, tracking IDs, Workday/employee IDs) and required account mappings were recorded on intake. Ambiguous or outstanding subtasks were resolved by assigning explicit owners (identity team, endpoint team, local coordinator) in the ticket and timestamping policy exceptions or manual delivery events. Jira automations and due‑date reminders prompted provisioning and escalated procurement, license shortages, or unresolved ownership; ticket states were corrected and login/profile details were explicitly delivered to local coordinators when visibility gaps occurred.

Credential delivery and automated flows: Automated credential dispatch used Okta Workflows with localized HTML templates and was triggered only after final copy and end‑to‑end testing. Expired or missing activation/retrieval links were replaced, reset links were resent and logged, and undeliverable bounces were resolved by correcting addresses and resending. When automation failed or user preference required it, credentials were delivered via admin‑initiated vault recovery (1Password/Safe), verified private addresses, or Microsoft Teams messages; problematic PDF attachments were resent as text‑only when recipients reported unreadable/blocked attachments. SignInLogs were used to confirm authentication failures that traced back to unused or unretrieved credentials. Routine reminders from Automation for Jira to deliver credentials were processed by retrieving credentials and sending them by the preferred channel when due dates were reached.

Account, username, delegated roles and multi‑account mapping: Workday→Okta imports that produced unexpected sign‑in names were accepted for first‑day access and documented; usernames were changed later where required. Where a single employee required multiple distinct accounts across identity domains (for example separate institutional, domain/server, and client‑admin identities), mappings of addresses to target systems were recorded and ownership of each account creation task was assigned in the ticket. Okta admin/delegated accounts (including accounts granted Workday‑Import permission) were created or requested when required to complete imports or delegated tasks; Okta support roles and delegated permissions were assigned and validated by access testing. Missing group memberships or license assignments were mitigated by temporary manual assignments, reference‑user (template) provisioning in directory systems, or by creating additional admin accounts from a reference AD admin user. License shortages were handled by reallocation or procurement escalation and recorded in ticket history.

Device procurement, staging, logistics and interim hardware: Purchase orders and PO numbers were recorded and reconciled in ticket history. Out‑of‑stock or late shipments were mitigated by loaners, alternate SKUs, direct supplier delivery, staged local pickup, or flagged for onsite pickup when lead time required. Power‑user SKUs were flagged to suppliers and staged; accessories (mice, docks, headsets) and third‑party licenses (for example TeamViewer) were requested and tracked. Delivery‑address or cost‑center discrepancies were corrected in ticket records and local coordinators were informed.

Device enrollment, OOBE diagnostics and remediation: Enrollment failures were investigated using Intune diagnostics (AppWorkload.log, Microsoft Intune Extension traces), Company Portal checks and client traces to identify failed in‑setup app downloads, network interruptions, or interfering recovery tools. Enrollment retries were performed on alternate networks (office LAN, Ethernet via dock, mobile hotspot) and recorded; problem devices were reimaged, erased and re‑enrolled when retries failed. Macs with ABM/JAMF misenrollment were erased and reprovisioned or staged for onsite setup; macOS admin‑rights requests were granted or documented when required by role and recorded in provisioning tickets.

Third‑party apps, vaults and service access: Where automated app provisioning failed, reference users and manual account assignments replicated expected access and temporary credentials were provided. 1Password vault access was provisioned for requested vaults (examples: EPOS, MyCampus, Test Accounts). Examples of manual fixes included provisioning Deskbird via the Okta dashboard, granting EPOS access using IU addresses, or triggering Salesforce password resets via internal ticketing. Application assignments for telephony (nFON/Cloudya), EPOS/CARE, myCampus, Salesforce, Confluence, Jira Software and Jira Service Management were documented and tracked per account mapping.

Network and remote‑access diagnostics: Remote access failures were investigated for credential, client and network causes; SSID details, dock/adapter observations and client logs were documented for escalation when VPN or client issues were tied to specific home networks.

Ticket workflow and recordkeeping: Tickets consistently recorded POs, approvers, tracking, delivery addresses, serial numbers, Workday IDs, credential activation/resend events, service‑account names, group membership, license assignments, AppWorkload.log and Intune traces, alternate‑network enrollment retries, Okta error codes (including 801c03ed), JAMF outage notes, SignInLogs where used, macOS admin‑rights requests, pickup or delivery notes, and any policy exceptions. When multiple accounts per employee were required, mapping of each address/account to its target system and the responsible team were recorded in the ticket to avoid ownership gaps.

Support verified institutional ownership and completed provisioning from the corporate OpenAI admin account. When accounts lacked an assigned corporate license, support assigned or activated the license and reissued invitations; support noted that admin approval did not necessarily equate to license assignment. Missing, delayed, misaddressed, or spam‑filtered invitation and confirmation emails were reissued (often located in Junk/Spam). For expired or invalid invite links (for example, “Oops. This invite was already accepted”), support verified org membership in the OpenAI admin console and had users sign in with their corporate email and use the password‑reset/“Forgot password” flow; when password‑reset or confirmation emails were not delivered after acceptance, support removed the user from the organization and reissued a new invitation, which restored account setup. Support documented that OpenAI did not provide SSO for these accounts; users had to create or set a password via the invite or password‑reset flow (institutional credentials alone did not log them in). When users landed in personal accounts or lacked the organization‑scoped web UI or Playground, support switched the active organization via Group Access or completed the onboarding “Create account” flow to produce the corporate account view. When users saw “not invited to any project” or project‑scoped features produced no responses, support added the user to the appropriate project/team so project features and the Playground returned responses. Support documented that OpenAI’s signup sometimes required phone‑number verification and that supplying a mobile number (for users without a Cloudya number) allowed verification to complete. In some cases support changed the inviter’s role (for example, Owner back to Viewer) and advised using a dedicated service account to send invitations to reduce confusion about which account sent the invite. Requests that produced no invite via the institutional form were forwarded to the specialist provisioning team, which processed them and delivered invitations or manually created accounts (often within about an hour). On request, support created separate corporate OpenAI accounts and delivered credentials; requesters were informed that GPT‑4 API access was gated by an OpenAI waitlist, so newly provisioned corporate accounts could be limited to GPT‑3/GPT‑3.5 until GPT‑4 access was granted. Support re‑triggered invitations when users could not complete signup within the invite validity window and provided links to internal orientation resources (GenAI @IU group homepage and the IU Learning Hub ChatGPT Playground guide). For Learning Path/onboarding e‑learning emails that did not arrive, support checked the Automation for Jira workflow, cleared pending approvals, and observed the onboarding email be delivered.

Initial onboarding and first‑login failures were traced to incorrect macOS keyboard/input layouts that caused typed (masked) passwords to differ from the expected password. Support confirmed or switched the macOS input/keyboard layout (for example German QWERTZ vs US QWERTY), after which typed characters matched and sign‑in succeeded. For activation/Okta onboarding flows support also performed live remediation as needed: resending welcome/activation emails and activation codes, sending Okta password‑reset links, and removing or re‑enrolling MFA; those actions sometimes restored web/phone access but did not always restore local macOS sign‑in. Repeated failed local sign‑in attempts had locked some local accounts; resolving the locked account state alongside input‑layout, activation‑code/MFA, or timezone discrepancies was required in affected cases. Recovery Mode password resets or full OS reinstalls did not restore access when the device remained on the wrong key mapping. When a device had the wrong physical keyboard layout or provisioning issues persisted after remote remediation, the device was replaced (vendor/smart‑support and shipping tracked) and the replacement with the correct layout restored onboarding in those cases.

Incidents were resolved by addressing two distinct causes and using alternate Apple IDs when necessary. For addresses already registered as unmanaged personal Apple IDs, users signed into appleid.apple.com and changed the personal Apple ID’s primary email to a personal address (commonly by creating and verifying a free iCloud.com address) so the organisation address became available. IT then created Business/Managed Apple IDs in Apple Business Manager and supplied the email and temporary password; users completed activation in a browser (several incidents produced account-creation emails that contained only the email and a temporary password rather than a verification link). Corporate devices — including iPhones, Macs, and Windows laptops during device setup — required explicit sign-out of the existing personal Apple ID and sign-in with the new Business/Managed Apple ID before provisioning completed. Separately, where the organisation domain was reserved or in use for Remote Management/MDM (preventing creation of an Apple ID using that domain), the immediate workaround was to create or use an alternative Apple ID (for example a personal Gmail address or a free iCloud.com address) to sign in to the App Store or device. Support staff provided hands-on assistance for users who required help changing account emails, performing sign-out/sign-in on devices, or activating Business/Managed Apple IDs. Apple notification emails advising that an IU address could not be used were observed in some cases.

IT support determined that onboarding coordination for academic project appointments was outside IT responsibility. The user was directed to contact their academic contact or their manager/supervisor, who were identified as the parties responsible for coordinating start dates, assignment details and onboarding steps. The ticket was closed after this guidance.

Missing, delayed, expired, or misdelivered corporate AI onboarding invitations were resolved by reissuing valid organization invitations or resending activation/confirmation links when time‑limited links had expired. When invitations repeatedly failed to deliver, administrators sent direct corporate‑email invitations as a fallback and checked spam delivery. Inconsistent, phantom, or incorrect membership entries in vendor admin consoles or workspaces (including workspace‑level services such as LangSmith) were removed or corrected so provisioning could proceed. Stalled internal approval workflows in SharePoint, Learning Hub/Learn365‑Player, Automation for Jira, or Microsoft Forms were completed or approvers were engaged so vendors could issue invitations. For cases where users encountered errors during initial signup or first sign‑in, support initiated password resets when requested and recorded that password resets resolved sign‑up failures in multiple incidents. For bulk or urgent needs, administrators manually provisioned users or centrally added multiple users; complex or remaining cases were escalated to the specialist/provisioning team which created accounts or reissued invitations and supplied registration details. Support confirmed account creation and successful sign‑in before closing tickets when confirmation was available; in some cases tickets were closed after an activation invitation was sent if no follow‑up or error was reported. Confirmations noted corporate plan entitlements where relevant (for example GPT‑4 availability or Plus‑license workspace membership). Support informed users that service sign‑in sometimes used credentials created during registration that could differ from Okta credentials and noted that accessing services via portal.office.com (WebApps) occasionally presented identical credentials.

Support advised users to enter the insurer's full name "Techniker Krankenkasse" (or its common abbreviation "TK") into the health-insurance search field to reveal and select the option. If the option remained absent, support directed users to contact support@getworkflex.com for assistance. The issue was resolved for the reported user after they typed/selecting "TK" and successfully submitted the form.

Incomplete academic onboarding was resolved by correcting tenant placement, restoring or creating the correct account and mailbox types, and reestablishing downstream entitlements, group memberships and licensing (Atlassian SSO, Microsoft 365 A5/A1, Adobe CC). Duplicate or retained '.ext' accounts and name collisions were resolved by verifying identity details and creating distinct external addresses where necessary; urgent starters were issued temporary credentials or credentials sent to hiring managers. Workday export errors (for example stray text in exported email fields or incorrect titles) were fixed in the source export and identity attributes so mailboxes and addresses synced correctly. When mailbox provisioning lagged, completing MFA and adding the account in Outlook macOS often triggered mailbox creation. EPOS/CARE/myCampus records and Moses roster visibility were added or corrected; Moses-team coordination restored roster entries where synchronization failed. EPOS/CARE instructor entries were created either by cloning a staff template or by IU support and mapped to libfstudy addresses; LIBF colleagues created libfstudy accounts and delivered credentials via the iu.org address in reported cases. Password-reset and email-delivery failures were resolved by validating account types and mail routing and coordinating with DNS and Auth0/CloudFront owners when authentication/redirect mismatches caused downstream omissions. Third‑party services were either bound to the corporate address or left on the prior sub‑brand and the state was documented for later migration. Procurement and hardware ordering issues were escalated when lead time was insufficient; purchase orders and cost-centres were corrected and vendor orders for standard-imaged laptops, tablets and peripherals were placed or expedited. Carrier tracking, address corrections, reroutes, split shipments and failed deliveries were recorded and retried, reordered, paused or cancelled when start dates changed or hires were withdrawn; satellite‑campus pickup arrangements and in‑transit hardware requests were coordinated with campus teams and asset management. Device enrolment issues were resolved by resuming paused activation flows (activation codes where used) and completing enrollment; intermittent background software-installation errors observed during imaging did not prevent final provisioning after the enrolment was resumed and installers retried. MFA was configured to accommodate user-preferred authenticators (including Google Authenticator) and Okta factors were provisioned as required; guidance was provided and credential delivery timed (or resent to hiring managers) to avoid activation expiry. Staff were assisted with Teams, Outlook and Okta setup on personal tablets and smartphones when requested. Onboarding-form validation edge cases, duplicate requests and data-entry errors were corrected in downstream systems and tickets were consolidated. Automation-for-Jira notifications and vendor tracking were monitored to confirm provisioning and delivery milestones.

Access failures were resolved by ensuring the active vendor or device session used the institution account rather than a personal, shared, or alternate SSO identity, and by ensuring the user had an institutional vendor account and any required vendor license or application assigned. For Adobe, resolvers signed out of personal Adobe IDs and signed into the institution (work/school) Adobe account which restored institutional licensing and Acrobat/Creative Cloud features. Where a user had no Adobe account or Adobe Cloud application assigned, assigning the user an institutional Acrobat/Creative Cloud license (including fulfilling license-request and manager-approval flows when required) restored commenting and other functionality. When browsers or SSO sessions auto-authenticated into the wrong institutional account, opening an incognito/InPrivate window or signing out of the existing SSO session and signing in with the required institutional identity restored access to onboarding portals and downloads. Where a preexisting personal vendor account could not be linked or merged (for example Calendly), resolvers created a new account on the institutional instance and assigned the user to it; where vendors provided content-transfer tools (for example Canva), administrators invited the user to the institutional team and used the vendor’s content-transfer function to move ownership and content. After SSO rollouts disabled shared accounts (for example Cloudinary), conflicts caused by personal accounts with the same email were resolved by removing or relinquishing the conflicting personal account or changing the personal account email so the organizational account and license could be assigned. On managed mobile devices, required apps were installed from the institution’s Self Service/MDM catalog (for example Google Authenticator); when an app was absent from the catalog, the issue was escalated to the application/catalog team so device installation could proceed.

Investigators confirmed the IU Shop customer accounts were restricted to leadership-managed accounts. The issue was resolved when the employee's manager requested and/or created the customer account through the brand@iu.org contact; after the manager-created account existed the employee was able to log in and place the order.

Support created the user’s OASIS account and copied a profile from an existing user to the allocated profile on the Walbrook-hosted machine. OASIS was confirmed installed on the designated Walbrook workstation (not on IU-managed endpoints). The user was instructed to connect to the Walbrook VPN and remote (RDP) into the designated Walbrook computer; follow‑up assistance was provided via Microsoft Teams.

Requesters were asked to submit the standard Software request via the Software - IT Service Portal and to use the portal’s "software not listed" option so requests were routed and an approver could be identified. When a catalogue entry lacked an approver, support added the missing approver to the request so it proceeded through the normal approval workflow. If an application was not managed by IT (for example, Connectedware/PMS), support informed the requester, provided the owning team’s service-desk URL, and closed the IT ticket as Done. Where onboarding form selections did not result in expected accounts (for example, EPOS/CARE), support opened follow-up provisioning tickets and coordinated with the application owner or provisioning team until credentials were issued. Hardware-order problems were handled by liaising with the vendor/ordering team, providing tracking details to the requester when available, and noting vendor-reported delays (for example, stock/backorder messages such as "waiting for Apple") that postponed delivery.

Service staff provisioned Salesforce user accounts and, when provided a reference user or permission template, replicated the new account’s profile and permissions; Key User permissions were applied when requested. When a designated reference user blocked the Automation for Jira approval workflow or approvals were required, staff substituted a valid reference user or escalated/forwarded the request in the Automation for Jira workflow and obtained approvals before completing provisioning. Where a Salesforce account already existed, staff enabled production access via the Okta Salesforce tile and confirmed activation/invitation emails were sent. Staff corrected typographical errors and replaced incorrect or temporary IU logins, updated user attributes, and reissued activation emails. Non‑production (UAT/Dev) access was handled via a distinct SalesTech Service Desk request. Integrated third‑party app licenses such as Deskbird were assigned by staff; other integrated apps (for example Twilio) were sometimes reachable from the Salesforce Okta tile while Salesforce Marketing Cloud requests were tracked separately. Attempts to activate eSIMs via QR codes sometimes failed; staff requested additional details (QR image, PIN/PUK, profile or article numbers) and left tickets pending or closed them when no further customer response was provided. d-velop invitations were issued when required. Onboarding tickets that included hardware procurement resulted in purchase orders for standard laptops and peripherals, arrangements for delivery or myCampus pickup, and scheduling of credentials to be sent on the employee start date. In cases where frontline support lacked permission to edit the internal SF Dashboard, staff directed requesters to submit the provided Microsoft Forms or routed the request to an authorized admin who completed the dashboard entries. Users were advised to report any missing permissions or settings after access was granted.

The issue was resolved by ensuring key form fields were placed into Jira's indexed fields so they became searchable. An Automation for Jira rule was implemented to copy identifying form fields (employee name, employee ID and other key fields) into the issue summary/subject header, and the Jira form configuration was adjusted so those fields were treated as header/searchable fields. After these changes, standard Jira search returned onboarding forms when queried by employee name or ID.

Issues were resolved after confirming the target product (Vonage, Cloudya, nfon, Twilio or external mobile/eSIM provider) and validating the reference configuration visible in the provider console or order system. Where provider accounts or entries were missing, misassigned, or blocked, telephony teams corrected assignments, restored or recreated provider accounts, or selected an alternative reference so the employee appeared in the provider UI. For site moves the user’s site was confirmed and the corresponding Cloudya phone-prefix applied so the user received the correct location-based number. Vonage naming and prefix problems were resolved by standardizing unit/role labels and updating account name prefixes. Pending approval states and provisioning/order approvals (including Workday JobProfil entitlement checks) were reconciled when they delayed activation or vendor order submission. Mobile eSIM orders were handled by obtaining required approval, then sending the automated order to the external provider (for example Conbato / cpg-requests@conbato.de) and the IU mobile orders mailbox (Mobilfunkbestellungen@iu.org), with instructions to send order confirmations and delivery scheduling to the contract holder. Provider account credentials and account metadata were recorded and telephony/mobile records were created or linked to the employee’s Salesforce record; designation/role fields were updated when provided. For Twilio, teams checked the Salesforce permission set "Single Sign On Twilio" and noted Worker accounts were often auto-created on first SSO login; when manual Twilio action was required, specialists performed Caller ID verification with the user and linked or added phone numbers to the Twilio account. Returning employees and reassigned resources were handled by creating new telephony accounts when needed and reassigning previously used email addresses, phone numbers, or extensions so ownership appeared correctly in provider consoles. When provisioning occurred alongside other onboarding systems, IU Safe Portal notifications were sent, the Cloudya client was expected to auto-install on corporate devices, and other accounts (MyCampus, Jira, Deskbird) were enabled in the same workflow. Hardware and software entitlements (laptop, iPad, monitor, docking station, headsets, Adobe Pro, EPOS/CARE references, purchase/serial numbers, shipping info) were ordered and tracked as part of the onboarding package and requesters/users were informed.

The onboarding page was removed by the designated specialist, allowing the content to be taken offline while leaving existing intranet permissions unchanged. The action achieved the goal of decommissioning the onboarding content without modifying user access rights.

Automation for Jira had been configured to require approvers for selected onboarding, Atlassian‑account, equipment, and temporary external account requests. Tickets entered approval workflows and produced Automation for Jira approval notifications and repeated reminders; when an approver completed the approval the system created the requested Atlassian or external account and downstream onboarding actions executed, with provisioning and access activation observed approximately 5–10 minutes after approval. When approvers did not respond, Automation for Jira sent reminders and, after the 14‑day approval window, automatically marked requests as declined which prevented onboarding actions from completing. On occasions where the approval UI did not display the Approve button, approvers used alternate/manual approval methods or support manually created the user accounts and issued credentials to complete onboarding. Requests were also delayed or flagged because start dates were in the future or invalid, due dates or lead times were too short, reference users could not be located, or request details were incomplete or ambiguous; support requested clarifications, remediated incorrect or duplicate ticket types, corrected reference‑user discrepancies, and recorded cancellations or 'wont‑do' outcomes when hardware or access was later declined. Hardware procurement and technician scheduling were handled separately from account provisioning; in cases where hardware was required support placed the order and confirmed that access credentials would be delivered automatically at the employee start date. Where a direct application entitlement was sufficient, support assigned application access and provided the Okta app URL; application‑specific workflows (for example EPOS) were routed to SelfService.

Support diagnosed access failures by first confirming whether an active account or an outstanding admin invitation existed and by clarifying the correct sign‑in portal (for example Okta vs Microsoft). Where no active account or invitation existed, support created accounts (including Microsoft service and external/test accounts) and reissued activation invitations, monitoring delivery and activation until completion. Licenses, named‑user seats, project roles, group memberships, and cost‑center/chargeback attributes were applied as requested. When onboarding workflows had removed direct invite capability (for example Confluence), license and seat requests were processed through the ticketing system and assigned by IT rather than relying on user‑sent invites. Common resolutions for silent or failed password resets, undelivered invites, and sign‑in redirect loops involved reissuing activation or password‑reset flows, confirming account/invitation state, and coordinating with the owning application team for application‑specific configuration. For automation platforms (Make) seat/license requirements were clarified with Corporate Consulting and onboarding was completed accordingly. Dedicated SSO test or vendor‑facing accounts were provisioned via ticket; requesters opened tickets for external‑employee or test accounts, IT verified and created the accounts, and coordination with the vendor restored test‑side access. Credentials and service‑account secrets were delivered over secure channels (for example 1Password) when applicable, and hardware or procurement actions were initiated for PMS and similar requests. Service accounts followed the svc.* email pattern and credentials were provided to requesters after coordination with relevant application owners. Support also handled cases where onboarding requests were submitted to external partner portals (for example careerpartner.atlassian.net) but remained in an “open” state with only automated acknowledgements and nonresponsive vendor or internal contacts: support confirmed ticket creation in the external portal and escalated or re‑routed the request through internal ticketing when required. Representative outcomes included restoring an institutional Zoom account using Zoom’s “Forgot password” flow; Calendly administrators sending invitations, creating accounts and assigning Teams licenses; Jira named‑user accounts created with Okta‑based first‑time authentication; d.velop and libfstudy accounts provisioned or activation invitations sent and portal ownership clarified; Salesforce and Vonage accounts provisioned with sales group membership and cost‑center attributes; Haufe/Care Academy issues escalated to People Projects when required; Egencia access confirmed through internal account issuance and procurement guidance when applicable; and dedicated IU Shop SSO test accounts created and coordinated with the vendor to restore shop‑side test access.

Power‑user onboarding requests were completed by building, verifying and shipping the requested device(s). Windows 11 or macOS was installed and validated and the requested power‑user account/configuration was applied. Required peripherals and accessories (for example: monitor, docking station, mouse, keyboard, wired headset) were included or recorded, and listed applications (for example: EPOS/CARE, myCampus, Confluence, Jira Software) were provisioned as requested. Device hardware was confirmed against the ticket, device serial number(s) were recorded, and acceptance of replacement devices from stock was noted when applicable. Devices were boxed and dispatched with shipping recorded in ticket comments, access credentials were scheduled or delivered, and the ticket was closed with shipment/status recorded.

Vendor shipments were tracked and managed with suppliers and logistics partners; vendors were asked for dispatch confirmations and tracking updates and tracking information was shared with requesters and recipients. Missing, partially delivered, or misdelivered items were escalated to suppliers and re‑ordered or express re‑shipped when necessary; multi‑package deliveries were reconciled and outstanding peripherals were re‑shipped or shipped separately. Cross‑border customs and duty issues were chased with couriers and customs authorities; in at least one case the courier was instructed to pay import duty on behalf of the employer to prevent the recipient being billed and delivery was subsequently confirmed. Where delivery to a campus or private address was problematic, orders were redirected to confirmed campus pickup points or private addresses were used after confirmation; campus‑routing ambiguity was clarified with local contacts. Hardware lead‑time expectations (approximately four weeks for standard orders) were communicated to requesters so equipment could arrive by start date. Peripheral compatibility issues were identified (for example docking stations with only one HDMI + one DisplayPort vs users with two HDMI monitors) and resolved by arranging compatible replacements, alternative cabling advice, or separate shipments of the required peripherals. Faulty devices were troubleshot remotely (resets, remote assistance, first‑login and password support) and replaced when defective. Account and multi‑application provisioning used template profiles; corrective actions included fixing identity sync and HR/source‑data errors (for example Workday/Okta mappings, job‑title or reference‑user corrections), enabling missing apps in Azure MyApps, and creating accounts so cloud apps (Salesforce, Jira, Deskbird, Office365) appeared. Credentials were delivered to IU mailboxes or to private emails when requested. Telephony integrations and WLAN access for campus locations were arranged on request; UK eSIM procurement was handled with the mobile provider (Global4) and required handset make/model details and a vendor quote before ordering, so quotes were requested after handset details were provided. It was documented when third‑party AI services required separate end‑user applications (for example ChatGPT/Copilot). Tickets were closed after order placement and tracking confirmation or when credentials/provisioning had been delivered and validated against the start date.

Onboarding and hardware holds were resolved after HR contact and ownership details were corrected and reconciled. Teams updated Workday records (private/personal email and phone) and resolved spelling discrepancies by confirming addresses and numbers with the employee; once the HR record surfaced on the Workday→Okta provisioning interface the user was imported into Okta and accounts were created. Where existing external accounts used a different email address those accounts were reactivated and the user confirmed the email change before federated linking. Pending onboarding approvals or incomplete HR paperwork were completed and recorded so the record appeared in the onboarding tool and provisioning resumed. Employer affiliation (which legal entity supplies hardware) and a shipping reference user/manager were clarified to determine procurement and delivery ownership; after recipient, shipping address, phone, delivery window and inventory/asset assignments aligned hardware was ordered. For urgent start dates teams arranged expedited shipment or local pickup as required, sent tracking details when items shipped, and provisioned devices to stated OS requirements. MFA/authenticator needs were confirmed and either configured on the device or provided to the user as part of account activation; login credentials and access details were sent automatically at account activation or on the user's start date.

Onboarding requests were processed through the IT Service Portal (Jira Service Management). IT created the requested corporate accounts and provisioned application access for users without corporate hardware, commonly including a corporate email account, Workday access, IT Service Portal access and requested third‑party/internal application accounts (observed examples: Atlassian/Jira/Confluence, 1Password, myCampus, nfon/Cloudya telephony, EPOS/CARE, Salesforce, OTRS). Initial login credentials or scheduled password‑reset links were delivered to the private/personal email address supplied by the new starter or to the requester. Automated workflows (Automation for Jira and API calls) were used to generate provisioning notifications and to schedule password‑reset links to be sent to the user’s private email on their start date. In cases where users reported sign‑in failures (examples: Outlook, Okta), IT regenerated credentials and sent them to the private email and attempted follow‑up contact; when users did not respond, tickets were sometimes closed as unresolved/unconfirmed after repeated contact attempts.

User accounts were created and time-limited credentials (14‑day validity) were delivered to the private email address supplied. The hardware order (laptop, docking station and additional peripherals such as monitor and headset) was placed and FedEx tracking was used. A requested delivery hold/postponement was recorded and shipment was scheduled after the specified week; however, vendor pallets were dispatched and FedEx sent tracking/notification emails to the employee’s private address, which led to uncertainty when the employee reported not having received the hardware. Delivery status and tracking notifications were reconciled with the employee and the private-email delivery of credentials was confirmed.

Accounts for Cloudya and Adobe Cloud were created and made available in the Company Portal; the Cloudya username was set to the employee's email. Hardware was ordered. Internal and external telephone numbers were assigned (internal 4456 and external +4940284683556) and the access credentials were sent to the private email address provided.

Provisioning followed standard IT procurement and ordering workflows and contingent-worker requests were processed via the Manage Contingent Worker Account where applicable. External IU accounts were created using the firstname.lastname.ext@iu.org convention; account notification and password-reset emails were sent to the contractor’s private email and scheduled to coincide with the start date. Application- and program-level accesses were granted and licenses assigned as requested (examples observed: CARE, myCampus, Salesforce, PowerApp, EPOS, Adobe Acrobat Pro DC); in one case Adobe was assigned and the user was instructed to download and sign in using the IU email address. Exchange/shared-mailbox access and distribution-list membership were applied where required and Microsoft 365 service access (Office WebApps via portal.office.com, Teams, Outlook, SharePoint) was confirmed; Azure AD provisioning logs were retained. Standard-user Windows devices (commonly Lenovo laptops) and peripherals were procured, serial numbers were recorded, and equipment was prepared and shipped to the supplied private or internal delivery addresses; carriers used included TNT and DHL and shipping confirmations/tracking numbers were recorded in the ticketing system. International shipments sometimes incurred additional transit delays. In some cases workstation/PC builds failed or encountered unspecified technical issues that caused multi-day delays; those incidents required extended troubleshooting and collaboration with regional colleagues (for example, Canterbury teams) before the computer build was completed and the account fully provisioned. Cloudya phone numbers were provisioned when requested. Several tickets lacked detailed error messages or technical logs, so recorded resolutions concentrated on account creation, license assignment, access grants, hardware procurement records, and noting when hardware-build troubleshooting delayed readiness.

When HR records or the integration feed were missing, incorrect, or duplicated, the correct personnel/applicant number was requested from HR/Academy and the user import retried; provisioning resumed and was reconciled after the source‑system update. Where automated provisioning could not wait for final HR identifiers, accounts were created from available identity data with a placeholder employee ID (for example 000000); Active Directory and EPOS/CARE entries were adjusted and licenses were assigned. When the corporate mailbox or private‑email entry was incorrect or inactive, records were corrected and initial credentials were issued immediately; credential emails were sent to the user’s personal email when required and corrected private‑email entries were propagated to Workday so credential messages could be resent. Authentication failures (including Windows/MS Office sign‑on, Okta and VPN failures with error codes 782 and 691) were resolved by reissuing credentials or resetting passwords and confirming server‑side access (for example via Outlook Web App) before closing the record. Duplicate or secondary records (for example separate BD vs ND records, mismatched academy IDs, or an existing student account at a different domain) were escalated to HR/Academy for reconciliation and the correct mailbox/personnel ID was assigned to the active record. Returned‑to‑sender or wrongly‑delivered hardware was corrected by updating addresses and re‑dispatching shipments or staging devices for pickup; delivery and tracking details were recorded in asset management. Authenticator hardware (including YubiKey), Okta registration assistance, and Windows/image coordination for OS images and Windows‑dependent applications (for example Parallels Desktop, PowerBI Pro) were provided as required. For local or non‑Workday numbering systems (for example LIBF), Customer Services allocated the employee number after receiving the new worker’s full name and email address and confirmed the allocation so provisioning could continue. Student‑specific onboarding issues included accounts whose usernames pointed to study mailboxes the student had not been told about; those incidents were routed to student support, where technicians created or activated the student mailbox or, when immediate access was required, issued initial or temporary credentials to the student’s personal email and completed activation so SSO/EntraID tokens refreshed. Temporary passwords that permitted sign‑in on a single device while other devices and SSO‑integrated services repeatedly prompted were resolved by completing the first‑login/reset cycle, reissuing credentials where necessary, and ensuring SSO tokens and cached credentials refreshed so downstream services reauthenticated. When missing mailbox or directory details were later provided, technicians created or activated the mailbox, notified the manager that credentials had been issued, and noted that the account would appear in the global address list or intranet employee listing after directory/GAL/Workday sync completed. Cases where users were absent from the intranet employee overview were handled via HR/Workday updates or regional administrative inclusion requests; support directed users to regional administrative leadership or to submit a Workday change and closure occurred after HR/Workday populated the downstream directory. Some records remained open when users did not complete password resets or first‑login steps and were documented accordingly.

The network team increased Eduroam throughput at the Peninsula House site from 10 Mbps to 50 Mbps to improve onsite performance. Users were informed of the change and asked to report if slow connectivity persisted. The ticket was closed after the throughput was raised rather than provisioning alternate LIBF accounts.

A prepared and approved notification text was produced to explain the Windows 11 provisioning policy. The notification stated that corporate Windows 11 devices were provided without an automatically mounted local data drive and recommended using existing cloud storage options (Personal OneDrive or Team OneDrive) for user data. The message also specified that if a local drive was required it had to be requested through the IT Service Portal and clarified that locally attached drives were not backed up or supported by central IT.

Support clarified that creation of test or fictitious accounts and institution-specific email addresses was not performed directly through the general support ticket. Student test identities were provisioned via the EPOS enrollment system, while institutional email addresses (for IU or LIBF domains) were provisioned through the central account/email provisioning processes or via the KM/account teams. Requesters had supplied Care IDs or desired addresses and noted that external Gmail accounts were technically unsuitable for Course Feed integration; those account requests were not completed in the support ticket and were closed as 'Won't Do' or marked obsolete when the requester did not pursue the official provisioning channels.

External, cloud‑only and legacy on‑prem AD records were consolidated into standard internal identities by converting external sign‑ins to firstname.lastname@iu.org primary addresses and preparing importable records for identity‑sync/DS. Legacy on‑prem objects were reactivated, renamed or flagged so identity‑sync could reconcile them; duplicate accounts created by imports were removed or merged and the correct account was selected as primary. Okta import conflicts and missing Approve controls were cleared by removing import conflict markers and completing approvals or reinitializing Okta/AD accounts to restore visibility on the provisioning/import interface. In at least one case the Workday‑Okta interface was inspected and the incoming Workday record was confirmed to have matched an existing .ext account, explaining why a new AD account had not been created; records were reconciled so the correct internal account could be provisioned. Exchange/GAL/address‑book collisions were resolved by renaming or removing conflicting address records so mailboxes and GAL entries no longer blocked provisioning. Entitlements, group memberships and licenses (examples: Office 365 Desktop A5, Atlassian SSO, Learning Hub/LMS, myCampus/Care, EPOS, Adobe Creative Cloud, Windows/Teams groups and Salesforce roles) were reconciled and reprovisioned and application‑level role parity was verified and corrected. Corporate telephony numbers were assigned and hardware (Windows laptops, Dell notebooks, macOS devices and peripherals) was ordered and shipped under recorded purchase orders; missing or empty package contents were investigated and claims or replacements were coordinated. macOS devices were reset/reimaged and joined to the directory when applicable. MFA/authenticator setup guidance and account access details were delivered to alternate/private emails only when required, and password‑reset messages scheduled to private addresses were reassigned or withheld once accounts were internalized. Cutover dates and welcome‑mail timing were coordinated to avoid confusion. Jira automation and onboarding tracking managed due dates, hardware inventory, reprovisioning tasks and shipping status throughout the process. Where onboarding rules had enforced a single profile and blocked issuance of role‑specific institutional emails (for example iu‑study.org student addresses when a user already had an iu‑akademie address), required domain‑specific student addresses were provisioned as secondary aliases or as a dedicated mailbox/profile mapped to the same internal identity; import preparations were updated to detect existing iu‑akademie addresses and prepare iu‑study.org aliases or manual exceptions, and student support was engaged to complete registrations that required manual intervention.

Support reprovisioned accounts or regenerated time‑limited activation/registration/password‑reset links so users could complete initial account setup. Administrators used Okta password‑reset actions and Okta Workflows to produce new initial sign‑in links or temporary passwords; an Okta‑initiated password reset produced a new Microsoft 365 password‑creation link when an earlier link had expired, and technicians issued password‑setup emails and completed required MFA setup guidance for Office.com sign‑in. For Salesforce, administrators sometimes cloned an existing user/profile and triggered a Salesforce password reset (reset links were often time‑limited, e.g., ~24 hours). When users could not access the support portal because accounts were not yet active, support sent password‑reset emails or temporary passwords to an external email address or phone and provided sign‑in instructions. Support recommended signing in through SSO entry points (for example the intranet or the Okta dashboard) when direct links had expired and clarified system‑specific username formats (for example myCampus short usernames vs Office 365 email addresses and external‑instructor '.ext' addresses), noting that passwords were not shared across systems. Where activation codes were not delivered due to an integration/delivery‑layer fault (for example mylibf), IT diagnosed and repaired the integration so codes became deliverable again; affected users were advised to reattempt activation after the fix. For other service‑specific cases (for example Nfon/Cloudya), support resent access/activation links. Accounts managed outside central IT (for example external Gmail) were referred to the provisioning owner.

Support validated that affected accounts and application assignments existed in identity systems and found most access failures correlated with provisioning timing and downstream propagation. In many incidents services became available after identity propagation or when asynchronous downstream synchronizations finished; Twilio and Calendly links commonly became functional when rechecked, and Egencia activations were observed to complete asynchronously — frequently within 1–3 days but sometimes taking up to 4 days. Workday‑linked services were confirmed provisioned by IT but commonly remained inaccessible until HR activated the Workday profile. For Windows 11 OOBE cases logs showed PIN setup sometimes stalled while Company Portal and other management apps had already been installed but were not immediately visible; users located Company Portal via search and proceeded to install Office 365/Teams/Zoom. Support provided device re‑setup guidance, Company Portal install information, and observed that app provisioning and installs could take up to about two hours and were more reliable over a wired LAN connection. VPN and replacement laptop setup issues were handled through the same device re‑setup and Company Portal workflow; where failures were caused by provisioning, access became available after propagation and retrying. For travel-related activation delays that could not be expedited, users were directed to einkauf@iu.org. A subset of cases involved the IT onboarding portal failing to complete the device activation step or failing to accept error submissions without producing error codes; these incidents were recorded but frequently lacked detailed remediation steps in the ticket thread. A recorded replacement‑laptop case documented Office repeatedly prompting for a product key and Outlook reporting 'Uni‑Konto abgelaufen ist' while Teams continued to function; that ticket did not include a final resolution. Overall, most observed access failures resolved after identity/ licensing propagation or completion of asynchronous downstream syncs.

Provisioning tasks for Viewneo accounts/subaccounts were completed but content availability was handled locally. For the Freiburg site a subaccount was created and the provisioning task was confirmed complete; investigation showed the account had no uploaded playlists or media items, which caused the absence of playback. Content responsibility was assigned to the Freiburg local contact and account credentials plus usage tutorials were prepared and handed over. For Bonn the account s.viewneo-bonn@iu.org was created and two licenses were assigned; the ticket recorded the provisioning as completed with no further actions documented.

Support confirmed the correct LIBF tenant/domain and approver with stakeholders and provisioned the required accounts and service records in the appropriate LIBF tenant. For students and Handshake workflows accounts were issued in LIBF’s Microsoft student tenant (name.lastname@libfstudy.ac.uk); apprentices or cohort workflows used LIBF’s Google tenant and tester-account spreadsheets were shared with stakeholders. EPOS teacher records and CARE access were created where required (including for external domains such as walbrook-study) so staff could be assigned tasks. For Brightspace/myCampus access support ensured an Oasis contact record and LIBF Number existed and that student registrations/subscriptions were present before granting access. Where users were blocked by unexpected MFA/Authenticator prompts or did not receive password‑reset emails in the LIBF mailbox, support coordinated with LIBF tenant administrators and the IU identity team to remove or reset authenticator registrations and to confirm Exchange mailbox provisioning/activation before retriggering password resets. Where existing external licences or accounts (for example Zoom) needed reassignment, support transferred licences/accounts to the new LIBF account and triggered activation. Account credentials and login details were delivered to the user’s iu.org email or, when necessary, to requesters via IUsafe secure email. Requests that required actions outside tenant/account creation (for example laptop provisioning, device/mobile telephony, shared‑mailbox OASIS/profile replication, or SharePoint site‑owner permission grants) were forwarded to the relevant specialist teams. Support also requested missing user provisioning details (full name and contact details) when initial requests lacked them.

The issue was resolved after the user's browser history and cookies were cleared and the browser was restarted; the module state updated and the final assessment became available. Where the problem persisted beyond a cache/cookie clear and restart, the case was escalated to people-projects@iu.org for further investigation.

The failures were traced to an enrollment/policy configuration issue on the identity backend (Azure AD or a federated identity provider such as Okta). The incidents were resolved by applying a server-side change to the identity/enrollment configuration; after the backend policy change propagated (typically within minutes), affected devices that retried initial sign-in completed the device join/OOBE process successfully. In at least one case an end user retried sign-in during support contact and setup completed immediately; support guidance in another ticket noted sign-in became possible after a short propagation delay (~5–15 minutes).

Support reviewed each ticket and determined requests created on non‑onboarding or incorrect Jira forms could not be converted into onboarding/employee‑starter requests and therefore did not trigger automated myCampus or Microsoft 365 provisioning. Requesters were informed that initial‑equipment/access tickets must not be created for existing employees and were given the correct onboarding or access‑request form link in the IT Service Portal (for example, the Mitarbeitererstausstattung/employee initial equipment form). No hardware or account provisioning was performed until the proper onboarding form was completed. Tickets were closed after guidance was provided to resubmit using the appropriate onboarding form so the provisioning workflow and approval automation could run. Support also noted Automation for Jira approver/waiting‑for‑approval messages in ticket comments and recorded when Automation for Jira auto‑closed tickets due to inactivity (e.g., after 14 days with resolution set to 'Done'), advising requesters to use the correct form to avoid duplicate requests and to prevent disruption of automated onboarding processes.

Support engaged the external partner directly and used a direct LIBF contact as a workaround rather than creating an internal LIBF account. No internal mailbox was created and the request was closed with outcome recorded as 'Won't Do' because the account type could not be provisioned internally.

The user’s Okta password was replaced with a simpler secret that avoided characters that differ between German and English layouts (avoiding swapped letters such as Y/Z and problematic special characters). During the subsequent OOBE run the keyboard layout was verified/set to German so typed input matched the account password, and the sign‑in completed successfully. An example password used in the ticket was moh3To!f4v to illustrate a layout‑neutral choice.

The requester was directed to submit the access request through the dedicated 'New Contingent Worker Account - IT Service Portal - Jira Service Management' onboarding form. No account provisioning occurred from the original general ticket; once the correct contingent‑worker form was identified and communicated, the case was closed pending a formal contingent‑worker submission.

The Power Automate flow 'OnboardingLetterNewHires_Dataverse' was escalated to the specialist team and the flow was adjusted by a developer (Jens Streicher), after which the missing onboarding letters were sent as expected. In a separate case the lack of credential delivery was traced to conflicting/incorrect start dates in HR data which prevented the scheduled midnight automation from firing; the start‑date data was corrected and manual provisioning was applied while the scheduling behaviour was validated. SharePoint list hygiene (previously recommended cleanup) was noted as relevant to reliable runs.

Investigations identified two related failure modes. One was metadata-propagation failures: approver or HR metadata entered (or expected) on request forms was not consistently propagated through the Jira-to-provisioning pipeline, leaving approval state unset in downstream automation and causing requests to stall, be auto-closed as 'Won't Do', or be rejected by Atlassian provisioning APIs. The other was form design/validation failures: approver fields were sometimes missing or not clearly exposed to requesters, or fields were present but not marked required, allowing submissions without approvers or with invalid HR values (for example salutations/titles). Recorded remediations and outcomes included: documenting incidents as workflow/approval-propagation issues; removing incorrectly created Atlassian users when discovered; requesters recreating worker records with corrected salutations/titles and including the required approver/CC so provisioning could proceed; manual creation of at least one Atlassian user with a scheduled password-reset to the user’s private email for start date; advising requesters to check account invitations (including spam) when applicable; and, in some incidents, changing form configuration (required-field flags) to prevent empty submissions. In at least one matched case no form change was implemented and the automation closed the ticket as 'Won't Do'. All actions and outcomes were recorded in the relevant tickets to inform future onboarding requests.

Support investigations found existing student/Dozenten accounts that conflicted with the requested staff account creation; in the reported cases IT staff confirmed the presence of existing usernames and that password resets for those accounts were subject to the student account processes. One user resolved the conflict themselves after being informed; in other cases the account creation was blocked until the existing Dozenten linkage and HR/start‑date data were clarified so the correct account type could be provisioned.

Support paused fulfillment of access requests that arrived outside the standardized onboarding workflow and instructed requesters to resubmit via the onboarding form. The ticketing team recorded that Workday account provisioning, corporate e‑mail provisioning, and Microsoft 365/Office 365 license assignments required a formal onboarding ticket; in the absence of such a ticket accounts and licenses were not created and requests were sometimes auto‑closed. In affected cases IT provided the requester with the required onboarding procedure and intake guidance, and provisioning proceeded only after a compliant onboarding ticket was opened so the requests could be processed according to established onboarding integrations and rules.

Support verified whether a valid, system‑local reference user and explicit application/rights details had been supplied and acted according to what was present. When no reference user or an invalid reference user (for example a person without an account in the target system) was included, the provisioning process had applied the standard/default AD group set for the target account and the requester was informed that a valid reference user and explicit application/rights were required to copy non‑default permissions. When a valid reference user was provided or substituted, support confirmed scheduling details (for example the target’s start date), clarified which applications and exact rights were needed (for example specific CAMA reports/tools versus broader roles), inspected onboarding‑interface flags and automation/approval state (for example Automation for Jira approvers and due dates), and provisioned matching AD groups and application roles in the target systems (Salesforce, Oasis, CAMA, MyCampus). For MyCampus specifically, support assigned the required global role (IU Thesis Teacher) via Website‑Administration → Nutzer/innen → Rechte – Globale Rollen zuweisen and verified the assignment. Support also coordinated outstanding items such as hardware procurement and outstanding approvals; the requester was notified to report any remaining access gaps.

Multiple onboarding incidents failed when interactive authentication at Windows 11 OOBE did not complete or when users expected a VPN sign‑in option. Documented remediations and observed outcomes included:

Across incidents, definitive recoveries frequently involved OEM imaging/reimaging or hardware replacement, though at least one documented non‑imaging remediation (internal script) restored enrollment. A persistent limitation for troubleshooting was sparse diagnostic detail in many tickets.

Support inspected the report but did not modify the handbook because it was not produced or managed by the IT team. No technical remediation was performed; instead the user was directed to contact their manager or the onboarding organiser to obtain an updated handbook or request that the broken links be fixed by the document owner.

Support requested and recorded a complete postal address and the mandatory Salesforce reference user when those fields were missing. Where requesters did not provide required address details or a reference user, no hardware order or Salesforce provisioning occurred and the request was ultimately closed without remediation. When private delivery addresses were unavailable, support confirmed an alternate delivery destination (for example, a local campus) with a local contact and placed the order to that site; confirmation from local staff indicated the shipment was placed. For delivery failures caused by incomplete address elements (for example a missing building/suffix such as “Meierei”), tickets were resolved after the address was corrected and packages were reshipped or located, although some tickets lacked detailed remediation steps. Resolved tickets contained either confirmation that shipments arrived or that an agreed delivery destination and order placement had occurred.

The package delivery was verified with the carrier: the FedEx shipment was delivered on 2025-10-22 and the recipient had received FedEx notification emails at their private/personal email address. The ticket was closed after confirming hardware delivery and notification receipt to the personal email.

An administrator generated and sent a password reset to the user's private/personal email address, which restored access and closed the ticket.

No confirmed remediation was recorded in the ticket. Support documented that the problem was suspected to be caused by local DNS filtering or a home‑office network blocker (examples noted: Pi‑hole) or by transient connectivity issues. Support advised following the portal's on‑screen instructions, using the recommended browser (Edge), and retrying access from an unrestricted network environment; no further confirmation of a permanent fix was captured.