Support enabled the Qualtrics application in Okta and noted a 5–10 minute propagation window; when the Okta–Qualtrics link was intact, launching Qualtrics from okta.iu.org restored access after propagation. Where Okta logins still failed because the underlying Qualtrics user record had been deactivated, a Qualtrics administrator reactivated the user in the Qualtrics console and reactivation restored Okta-based logins. In several cases support verified that a Qualtrics license remained assigned but ownership/control of reactivation lived with the research or people-products teams; users were referred to research@iu.org or people-products@iu.org for account reactivation or provisioning. One case showed a password-reset email was not delivered from the Qualtrics sign-in flow and the user later regained access only after reestablishing Okta SSO — indicating password-reset flows from the Qualtrics sign-in may not resolve SSO-managed account access.

Issues were resolved by completing the Qualtrics invitation/registration flow when applicable: users followed the Qualtrics sign-in path and used the 'new user? Set your password here' flow with the expected username format (email+#iugroup) to trigger a confirmation message; the confirmation email's set‑password link (which expired after about six hours) was then used to establish a password. For Okta-linked accounts, launching Qualtrics from okta.iu.org restored access in several cases. Outdated or incorrect entries in browser password managers were identified as a contributing factor where saved credentials interfered with the sign-in/reset flows. In cases where provider-side checks showed the account existed but sign-in still failed, the Research Team or account/content owner restored access (support referred users to the Research Team/contact email research@iu.org), and access was subsequently reinstated by that team.

Administrators enabled the Qualtrics application in users' Okta accounts and assigned the appropriate XM tile/license; Okta changes were observed to propagate within about 5–10 minutes and restored access via the Okta dashboard (okta.iu.org). Approval-workflow errors were corrected when the wrong approver was listed by updating approver notifications or having requesters resubmit with the correct approver. Requests that had been submitted using the employee equipment form were identified as the cause of misrouting because that form triggered backend automations that could create new accounts and leave requests awaiting approval; affected requesters were redirected to the SelfService/software request form where Qualtrics is listed in the catalog. Support teams that did not have Qualtrics user-management rights confirmed they could not grant access and the requests were routed to the central provisioning contact (people-projects@iu.org) for account provisioning.

Platform-level Qualtrics accounts were provisioned via Okta, but dashboard/board-level and survey-level permissions were controlled by the dashboard or board owner, HR/people-analytics teams, or the user’s manager. Support created accounts and enabled platform access through Okta, and in multiple cases the specialist team or the dashboard/board owner granted the missing dashboard or board permissions and access was restored. Some users’ accounts showed only specific product modules (for example, 360 Participant Portal and Manager Assist) rather than the Survey builder after provisioning; support noted that assignment of board- or survey-level access and some module visibility were not adjustable by IT. For Pulse surveys, results were not retrievable while the survey remained active and only became available after the survey completed. Several requests were forwarded to the specialist team when owner-level changes were required, and users were directed to seek access from the dashboard/board owner or their manager when appropriate.

Support validated the sender identity used for no-reply.studentfeedback@iu.org on the IUG Qualtrics AWS SES account and found that another sender address (research@iu.org) was not authorised on the IUG Qualtrics account, which prevented sends from that address. Qualtrics reported that reminders were sent in high-frequency bursts (example: 300 messages in ~20 seconds), and advised review of AWS SES logs and any account sending limits; identification of the unauthorised sender address and the burst-sending pattern explained the elevated reminder failure rates.

Support modified the UKFRSUR bulk/survey selection logic to exclude registrations that had been closed or credited for non-payment. The change was deployed and confirmed to stop further survey sends to ineligible registrations.