Access failures were resolved by restoring the Okta/Azure AD Deskbird application assignment or by reactivating or reassigning Deskbird licenses, repairing Okta↔Deskbird provisioning/integration, creating missing Deskbird accounts and adding users to the correct Okta groups, or unblocking/re‑enabling users in the identity provider. Authentication loops and indefinite app-loading errors were resolved when application assignment or provisioning issues were fixed or when the Deskbird API/vendor service was recovered. In one case an outstanding password‑reset request was cleared and access was restored. Where licenses had been auto‑deactivated for inactivity, reassigning or reactivating the license immediately restored sign‑in. Workspace- and room‑level booking permissions were handled separately when users could log in but could not book specific rooms. When self‑service catalog automation or vendor provisioning had removed Deskbird, the app was temporarily hidden from Self Service and license/access requests were processed manually via Jira Service Management until automation was repaired. As a temporary measure to stop notification emails when users could not unsubscribe due to SSO, administrators deactivated the affected Deskbird accounts. Changes typically propagated in about 5–15 minutes; some users regained access immediately by opening the Okta direct app link while propagation completed, and the Deskbird tile sometimes appeared only after refreshing or reopening the Okta dashboard. Browser troubleshooting (clearing cache/cookies, incognito mode, or a different browser) was commonly attempted but definitive resolutions were identity‑provider entitlement reactivation, assignment regranting, license restoration, account creation/unlock, or integration/API repair. Vendor-side Deskbird API outages produced the same application‑assignment or authentication failures across multiple users and access was restored when the vendor’s API/service recovered.

Access failures were resolved by restoring or re-creating the user’s Deskbird account state and ensuring provider-side provisioning and any required app/group/license assignments had propagated before retrying sign-in. Typical successful actions included reactivating/unlocking the Deskbird account, making the Deskbird application visible or explicitly assigned in the IdP (Okta or Microsoft) and running IdP provisioning/workflows; changes typically propagated in ~5–10 minutes. Several cases required reissuing a Deskbird license via the organisation’s Self Service portal; those license requests sometimes required cost‑center approval before sign‑in succeeded. For persistent Microsoft SSO or other stubborn failures Deskbird support removed the provider-side user record so the user could re-provision and sign in. Some incidents were resolved by assigning users to the correct Deskbird groups bound to room configurations, re-sending desktop/mobile invitations and having users complete the invitation flow; missing locations/rooms were handled by the organisation’s Real Estate/room‑provisioning team via Jira Service Management. Mobile clients occasionally reported the account as disabled while the IdP showed it active. When the problem was isolated to the Microsoft Teams integration, rehabilitating/restoring the Deskbird Teams app resolved the error and restored access. A subset of outages coincided with intermittent Deskbird API instability; unresolved cases were escalated to the Deskbird admin/specialist team. Users were notified when accounts were restored, re-created, or when deactivation was traced to Deskbird’s inactivity/license‑revocation policy.

The issue was resolved by aligning the stored email and account entries across Active Directory, Okta, and Deskbird and restoring the user's Okta group membership. Deskbird support updated the user's stored email to the correct primary address (removing/merging the misspelled duplicate where present). Active Directory entries were corrected so the primary SMTP/proxyAddresses and username matched the correct email, which resolved Microsoft-account login failures. An Okta administrator re-added the user to the Deskbird access group used by the IU-Group application. Because some applications were SCIM-provisioned and others were not, manual corrections and reprovisioning were applied where automatic sync had not propagated. After AD, Okta, and Deskbird email and group memberships were aligned, SSO authentication succeeded and the user regained access.

Investigations repeatedly found a small set of root causes and specific remediations that restored Deskbird access. Resolved cases included: correcting room/workspace visibility and access lists (for example switching Flex Desk settings, restricting meeting-room visibility, or restoring professor-office access) and updating seating-plan and map configurations so desks and pool vehicles were correctly represented and bookable. Booking rights were restored by copying an equivalent colleague’s permission set or by having Real Estate add users to the required Deskbird groups; company and group entries were aligned with Workday dynamic groups and Azure AD attributes, with temporary AD-group workarounds used where necessary. Office- and site-level locks were escalated to Real Estate/building owners via the Real Estate Portal/Jira Service Management and were unlocked only by those owners when appropriate. Authentication- and session-related denials were resolved by re-authenticating via Okta, clearing stale browser/session or Teams embed state, or using the browser SSO path when Teams embedding failed. Parking access returned once the separate parking function was enabled on the user’s Deskbird account. A subset of incidents were caused by licensing or approval workflows: tickets documented that access remained blocked until a license was granted or an approval completed via the service portal/automation workflows. Support also recorded cases where users were asked to retry and no further feedback was received (tickets were assumed resolved or were later closed for inactivity). Finally, some requests to restore admin or proxy booking rights were declined for policy reasons and were closed as “Won’t Do.”

An administrator located the target location (Duisburg) in Deskbird and updated the room entries per the requested mappings. The renames were applied as requested (examples included: 'Reception R 6.1' → 'Empfang'; 'Office R 6.2' → 'Empfangsbüro'; 'Office R 6.7' → 'Standortleitung Office 3'; 'Office 6.15' → 'Office 2'; 'Office R 6.8' → 'Office 4'; 'Office R 6.12' → 'Office 5'), and the changes were reflected in Deskbird.

A scheduled license cleanup was executed on 2025-12-12 to avoid being charged for inactive Deskbird seats. Inactive users were identified by manually reviewing Deskbird booking histories for the prior six months (Deskbird's API did not expose booking/activity datapoints), users with no bookings older than six months were deactivated in Deskbird and removed from the Okta Deskbird group. An attempt to enable attribute-driven provisioning for Real Estate failed during investigation because the Deskbird integration accepted only basic attributes (email, firstname, lastname) and did not accept the requested custom Workday fields or per-office assignment; no error codes were returned and unsupported fields were effectively ignored. The request to support custom attributes was forwarded to the specialist team. Automation for license cleanup was not implemented because the Deskbird API did not provide the required booking/activity data.

Deskbird developers released a Floor Plan update that restored seat highlighting from the personal booking overview. After the update the booked desk was highlighted on the Floor Plan for the selected date and showed the user's name and the desk designation/number when viewed from the bookings/booking overview.

Deskbird support confirmed that the Check-in option had been intentionally disabled globally for all IU offices. The vendor/SOL treated this as a deliberate change rather than a device-specific fault. Bookings remained valid without an in-app check-in and users were informed; no further IT action was required.

Access to Deskbird was confirmed and support provided temporary access workarounds while remediation was pending with the vendor. Support repeatedly provided the Microsoft Teams app or the mobile Deskbird app as the most reliable access method; users logged in via email and completed SSO inside Teams when the web portal failed. Troubleshooting steps that had been attempted (and that did not provide reliable fixes) included clearing browser cache and cookies, using private/incognito windows, and switching browsers; behavior was machine- and browser-dependent. Incidents were observed on Windows and macOS (including Safari) and sometimes followed Okta SSO/Okta Dashboard activity; the failures were attributed to intermittent connectivity or vendor-side service issues that could prevent the web UI from loading even after successful authentication. At least one case noted a recent YubiKey MFA enrollment on the account, but support did not confirm it as the root cause. Vendor remediation was awaited for the underlying intermittent connectivity/service failures.

Access problems were resolved by completing pending approval workflows in Automation for Jira and provisioning Deskbird access through Okta. After approver action, IT assigned the Deskbird license and enabled workspace‑booking permissions on the user's Okta account; a short propagation delay (a few minutes) was observed before access returned and booking resumed. Support provisioned the Deskbird application to the user's Okta dashboard and verified visibility using the Okta User Home/session_hint URL. Automation for Jira sometimes auto‑declined or auto‑closed requests (observed 14‑day no‑reply closure) or routed requests incorrectly when approvers or cost‑center data were wrong; tickets commonly required approver confirmation or cost‑center correction before provisioning completed. Site‑ or room‑level booking rights were not granted by SSO/license alone and were escalated to the Real Estate team (via Microsoft Teams) when required. For external/startup members, support provisioned Okta external accounts for each external user and coordinated access‑policy exceptions so those accounts could book site rooms (example: Munich). Requests that combined unrelated asks were routed back to the IT Service Portal self‑service intake so they reached the correct queue; standalone software installs were handled via the Company Portal. Resolved‑ticket artifacts commonly included the Self Service Request intake link, the Okta User Home URL, login‑error screenshots or stopped‑booking notifications, and any updated cost‑center information used to validate and complete provisioning.

The outages were identified as vendor-side Deskbird incidents (often confirmed via an incident notification posted in the IU Group Teams channel). In affected cases IT specialists contacted Deskbird support/engineering and waited for the provider to restore the service. When Deskbird was reactivated by the vendor (typically within about an hour) authentication and normal access were restored. Support verified successful logins and desk bookings (including via Okta SSO/Microsoft Teams) and noted that delayed email booking notifications were subsequently delivered. Affected users regained access after launching Deskbird from the Okta dashboard and confirming functionality.

Requests to add new resources or register relocated offices/workplaces were handled by confirming the responsible resource owner and then registering the room or workplace in Deskbird once required metadata was supplied. Administrators or the fleet manager created the resource after receiving the necessary details (for example: room name, campus/floor; occasionally a higher-resolution floor plan was requested). If required information was missing, an initial admin creation was reverted and additional information was requested before completing registration. When a room had disappeared from Deskbird, support manually re-registered/re-added the meeting room so it appeared again in booking lists; bookings that had been deleted or lost during the disappearance were not restored as part of the re-registration. Requests to block or restrict rooms from booking were escalated to Real Estate/room management because booking availability was controlled there; after Real Estate approved removal or blocking, the technical team removed the room from Deskbird so it could no longer be booked. Security or data-protection concerns submitted with booking/block requests were noted in ticket handling.

Incidents were resolved in two primary ways. Many cases cleared automatically after identity propagation between IU/Okta and Deskbird (typically ~5–10 minutes); after propagation the Deskbird application reappeared in Okta and users could sign in with the updated iu.org address. In other cases Deskbird Support manually updated the stored account email/username on their side; after Deskbird applied the change the account reflected the new iu.org address (observed examples included monika.kaluschke@iu.org → mona.kaluschke@iu.org on 2023-04-19 and lisa.redl@iu.org → lisa.nastl@iu.org on 2023-09-07). Some incidents involved duplicate Deskbird accounts for the same person; Deskbird Support consolidated or adjusted those records to restore access.

Transient Deskbird authentication failures were resolved by retrying sign-in or signing in via the Okta SSO portal (https://okta.iu.org/). Short account/permission propagation delays after provisioning were resolved by waiting (about five minutes) and then retrying login. Browser-side authentication errors on newly provisioned devices were resolved by clearing the browser cache or using a different browser. One incident that also involved inability to authenticate to corporate Wi‑Fi (CPG‑Corp WLAN) was resolved after the WLAN was configured to accept email+password logins. These actions restored Deskbird access and booking ability; transient cases did not require Deskbird account changes.

Support collected detailed repro information (locations, desks, app version, browsers) and requested a HAR capture; the user provided a HAR file of the failing booking actions. The collected HAR and repro data were forwarded to Deskbird support/development/backend for root-cause analysis and further investigation.

Access was restored after an administrator reset the user's Deskbird MFA authentication state and the user re-registered their FIDO2/security key; the reset cleared the Deskbird-specific MFA registration so the device could be reconfigured and subsequent logins succeeded. In cases where the Teams desktop app failed to recognize the user's email or security key, launching Deskbird from the Okta dashboard or using Deskbird in Chrome (or the Teams Web App) allowed successful authentication as a workaround. Troubleshooting steps that did not resolve the Teams-desktop-specific symptom included removing/re-adding the Teams connector and uninstalling/reinstalling the Teams desktop app.

The intranet start page link that pointed to Deskbird was replaced with the provided Okta bookmark URL (https://okta.iu.org/home/bookmark/0oa6337080xYmQ22z417/2557). The updated link was deployed on the intranet.

Support clarified that room planning and classroom allocation were handled by the Campus Manager or Course Management rather than the support team. The instructor (Hichame Zouak) was advised to contact the Campus Manager or Course Management and provide the course code (DSBBWLAPM01), the student count (18 students plus instructor), and the session type (in-person, 4 LE) to request a larger room. The ticket was closed after the referral.