Investigation found the module-offer enrollment configuration in the Simovative/CARE‑FS portal allowed student-initiated unenrolment for FS offers. The module-offer permissions for FS students were adjusted so student self-unenrol was disabled, the configuration for DLRHUG02 was corrected, and the change was propagated to myCampus2/LMS. A test profile was used to confirm the unenrol action could no longer be performed and logs showed no further unintended unregistrations.

Two root causes of incorrect or missing read‑aloud audio were identified and resolved. In one case an outdated audio asset had been packaged with the course; the content team re‑exported the correct English TTS/read‑aloud audio, replaced the old file in the course package, and deployed the updated asset to the Learn/MyCampus content store, after which playback presented the correct English voice. In a separate incident the course’s audio files were absent; the team recreated/regenerated the missing audio files for the affected course, deployed them to the Learn/MyCampus service, and confirmed the read‑aloud function became available again across web (reported on Firefox/Windows 11) and Android mobile apps (reported on Galaxy Tab S7 Android 13 and Galaxy S23+ Android 14). Post‑deployment testing verified restored and language‑correct playback in both scenarios.

The problem was attributed to audio production quality in the media assets. The media/production team reprocessed or re‑recorded the affected audio tracks and replaced the corresponding Kaltura/MyCampus assets. After the updated media was published, playback showed consistent levels and eliminated the reported dropouts.

The course booking page text occurrences were updated to show the new 8-week deadline, the outdated myStudium_Kursbuchung PDF was replaced with the revised version, and the automated confirmation-email template (sent within 24 hours) was edited to reflect 8 weeks. The English site localization and the embedded iFrame were also updated so both DE and EN pages presented the same information. Changes were coordinated with the Simovative integration to ensure the embedded booking widget matched the updated assets.

Three distinct root causes were observed and resolved. 1) Missing Office apps and mailbox access were traced to incorrect Microsoft 365 license SKU assignments in Azure AD; correcting the user’s license to the appropriate SKU allowed standard propagation (about 30–60 minutes) and Office apps including Outlook Web App and mailbox access appeared, restoring MyCampus functionality. 2) SharePoint/MyCampus “permission denied” errors were traced to the external IU identity not having site/page rights; granting the external account the required permission on the specific SharePoint resource allowed the instructor to open the page. 3) In several cases access failures were caused by multi-account/SSO session conflicts where the Windows primary tenant remained active in the Office web app launcher or web-based Teams, preventing the user from authenticating to the external organization; this presented as the web Office/Teams UI stuck on the wrong org while desktop or mobile apps behaved differently and Authenticator pairing initially failed. Those incidents were resolved by ensuring the external account was used in the web/Office context (for example by signing out conflicting sessions or authenticating in a separate browser profile or re-establishing the authenticator pairing), after which the Office app launcher showed the correct external org, Teams access appeared, and MyCampus resources became available. Tickets that referenced multiple email addresses (external IU vs personal) were resolved by confirming which external IU identity had the required license or SharePoint permissions and using that identity in the affected client context.

Multiple distinct root causes were identified and handled according to ownership and symptoms. Identity and SSO failures (SAML ACS blank/white pages, form‑resubmit prompts and session‑mapping issues) were triaged and escalated to identity/SSO teams and vendors; a minority were temporarily bypassed by reloads, browser changes or private/incognito sessions while vendors investigated. Cases where users authenticated to MyCampus but the downstream application returned an error were triaged with middleware and student‑import teams; HAR traces and session token exchanges were collected and provided to middleware or vendor teams for diagnosis. Embedded viewer and iframe display problems were traced to legacy, incompatible or mis‑deployed iframe endpoints; replacing endpoints with vendor‑compatible URLs restored embedded content (for example the MSE viewer) and fixing a mis‑deployed exam‑registration iframe restored scrolling. Empty dashboard iframes (for example Evasys) and similar failures were treated as either display/iframe issues or student‑data mapping problems and were escalated to evaluations/Evasys teams and vendors for reconciliation. BinderHub/Jupyter notebook failures that returned “Found built image, launching… Internal Server Error” were resolved after the BinderHub vendor applied a service fix and affected notebooks were verified working. Course‑materials failures that displayed misleading errors were traced to redirect URL mismatches interacting with LTI modules and were escalated to LTI/middleware teams for redirect normalization. Inaccessible registration, upload or download links frequently correlated with provisional or inactive course bookings, missing documents, deprecated activity types or missing vendor invitations/roles; normalising bookings/profiles or receiving required vendor invitations restored visibility. Several incidents were transient and resolved when the external service recovered; pragmatic interim access (direct vendor links, browser refreshes, different browser or incognito) restored visibility in many cases. Vendor feature rollout behaviour was recorded as a distinct cause of apparent 'missing' functionality: support verified cases where a vendor icon or entry was present in the UI but the feature was not enabled for that course, and ownership was handed to the course owner or vendor when non‑technical role/invitation restrictions prevented access. Submissions and folders stored in external vendor systems (Turnitin, Peddlepad, Simovative, CARE/LIBF, etc.) were outside IT‑OPS control and were escalated to the central/local examination office or the vendor for folder visibility and access. Vendor‑specific media playback issues in integrations such as Bongo were reproduced across multiple clients and were handled by the exam office or vendor support when no platform fix was available. Cases involving the E‑Assessment/Klausurensystem (EAS) that produced the vendor error “Wrong exmid… can’t be rated” or opened as an empty window were not resolved by client‑side troubleshooting (cookie clear, disabling add‑ons, browser switches) and were escalated to the Klausurensystem vendor and the examination office to reconcile exam‑ID mapping and backend processing; no IT‑OPS technical fix was applied in those incidents.

Access was restored by provisioning or correcting MyCampus and CARE accounts, credentials and privileges, and by fixing onboarding communications and approver assignments. Support created new CARE accounts from supplied identity details (including instructor-level accounts using institutional addresses and assigning Academy IDs where required), issued temporary credentials or sent the MyCampus/CARE password‑reset ("Forgot password") self‑service link, and confirmed which username form was required for sign‑in (CARE username or institutional email, noting some MyCampus instances use the institutional email as the username). It was confirmed that MyCampus accounts were created only after the first successful MyCampus sign‑in; where users had authenticated to CARE but never signed into MyCampus, an initial sign‑in led to account creation and administrators then provisioned requested permissions (for example by matching a reference user’s rights). Missing course visibility or instructor enrollment was resolved by confirming course membership and routing enrollment tasks to course management teams when needed. Missing admin or user‑management capabilities were restored by assigning appropriate MyCampus roles and explicit rights (for example Student Office role, group rights, tutor rights, lock/unlock privileges), and when users needed to match a colleague’s view administrators replicated the colleague’s rights and adjusted the user’s reference‑person setting. Support noted that account or role changes could require propagation time before updated views or enrollments appeared; records that could not be resolved by self‑service or local provisioning were escalated to MyCampus support, development or platform teams. Where attempts to change EPOS employee emails or assign the Employee/staff role produced HTTP 400 or 500 errors, investigation sometimes showed these were caused by use of the staff/employee login endpoint instead of the regular MyCampus login endpoint and were escalated accordingly. For requests needing a test student, support advised involving the immatriculation department to create a test student account in the specific non‑statistical format required so it would not count in Hochschulstatistik; once the immatriculation team created the test account, that account was used to sign into MyCampus to verify downstream services such as Speexx access and news delivery. Affected users and requesters were notified after changes were applied.

The failures were caused by local/ISP outbound connectivity interruptions that prevented the GrowthBook client from reaching external GrowthBook endpoints during myCampus login/registration. Symptoms included GROWTHBOOK_CANT_REACH errors across multiple browsers and devices, intermittent connectivity events in Datadog, and no backend request failures; standard browser troubleshooting (alternate browser, incognito/private mode, disabling ad blockers, clearing cookies) did not restore access. After the local/ISP network outage and normal internet routing were restored, GrowthBook calls succeeded and myCampus login/registration returned to normal. Observed error payloads (uuid, ac5Id/academyId, programId, bookingId, cohortCode) were used to trace affected requests in logs and monitoring.

Course bundles for the DMSD WPB offerings were created in DS Community (including a distinct bundle for WPB C mapped to the Studium Generale list) and each bundle was mapped to the DMSD program family in myCampus. Booking constraints were added to prevent duplicate/overlapping bookings across WPB lists. CARE↔DS Community↔myCampus course mappings and synchronization were updated and the changes were deployed to both staging and production. Functionality was validated with a test user. For immediate access cases where users were blocked from course content (for example the 'Exam Guide' and 'Examination Regulations'), a specialist temporarily restored access by manually enrolling the affected users into those courses.

Support clarified that the IU public website and faculty/teaching profiles were managed by a separate web/content team and that requests to create, publish, or edit profile content — including adding or linking text within a profile — were processed via the IU Meldeportal (Jira Service Management). Users were advised to submit a request through the Meldeportal so the website/content colleagues could process, publish, or update the faculty/teaching profile. Tickets were closed after this guidance was provided.

Support confirmed the IU Learn mobile app was no longer maintained and was expected to be removed from app stores in the near term; the myCampus app was identified as the supported replacement. The product team indicated it was unlikely to add an in‑app deprecation notice in IU Learn because the app was out of maintenance. Specialist staff confirmed no further view updates would be made to the Learn app; users were advised that some non‑BWL scripts could still be found by searching (occasionally appearing under the "Betriebswirtschaft & Management" view). For the LIBF MyCampus portal, teams developed and released a new dashboard course widget and rolled it out as part of transitioning dashboard ownership from myCampus Classic to myCampus2; during that rollout the IU Learn app was set to maintenance mode so it no longer appeared in module and checklist views. Tickets were closed after these explanations and UI changes were accepted.

Investigated the overnight Pearson results file and identified an issue in the incoming file that prevented normal import. The file/import issue was corrected and the results feed was reprocessed through the results-import system. After reprocessing, the affected student's result was confirmed as visible in the student record.

Backend selection logic, aggregation rules and DokGen templates were corrected and redeployed to address document-generation, period selection and template wording issues. Period selection was restricted to valid selectable periods and listed newest‑first; the default/selected period was made to derive from the student’s actual enrollment/active/leave state so test, active and beurlaubt students no longer received incorrect defaults. Validation and bounds logic that had prevented generation beyond arbitrary future limits (manifesting as a misleading "You cannot create a certificate for the past" error) were investigated with the vendor (Simovative), clarified with product and customer stakeholders, and corrected so certificates could be created for appropriate future periods. The "only re‑registered semesters" filter was fixed to coexist correctly with the 3‑month‑before‑semester‑start rule, and the 3‑month behaviour was corrected so students with valid start dates could generate Immatrikulationsbescheinigungen at the appropriate time. Certificate of Study (SIMO_9917 / MyStudies) aggregation was changed from semester‑level to support explicit quarter‑level aggregation, preventing incorrect aggregation for mid‑semester intakes; semester/quarter identifiers and validity date ranges for quarter‑structured programmes were corrected. Document templates and canonical wording were updated across Immatrikulationsbescheinigung, Certificate of Study and Teilnahmebescheinigung/Certificate of Attendance; duplicate campus/location/address lines and extraneous address fragments were removed and wording harmonised. A previously observed per‑student generation error was resolved and the DokGen→MyCampus/MyStudium delivery and visibility integration was fixed so generated documents were reliably created, visible and downloadable. A field‑level display issue in the Immatrikulationsbescheinigung (the Zeitmodell line) was cleaned by the specialist team to remove extraneous graphical characters, and MSD Immatrikulationsbescheinigung printing was restored for affected records. Additional individual cases of reversed semester selection were identified and escalated to the specialist team; the investigation indicated these anomalies could be triggered when student‑record fields (for example a Hochschulsemester start offset versus an empty or inconsistent Statistic field "Already studied at university") were inconsistent, and specialist remediation and data corrections were engaged to address such per‑student mapping issues.

Developers diagnosed a failing database query in the MyCampus timetable view, implemented a code fix and deployed it to production. After the deployment the timetable rendered correctly in MyCampus for the affected user and related error logs ceased; the fix was verified and the incident was closed.

Investigators found the root cause was that anchor target sections were often hidden or removed from the DOM by group/permission restrictions or by front-end logic, so the browser could not scroll to targets even though the URL contained the anchor. Remediation involved ensuring the anchor targets were present for the user (adjusting section visibility or group membership) or changing the front-end handling so links only attempted in-page navigation when the target is visible. After correcting section visibility or link targets the anchor navigation resumed functioning.

Support compared the user’s PA/group and permissions with reference users and aligned the user’s permissions to match those references. Site/location assignments in Care were corrected (expanded where only a subset of sites had been assigned). The Care→myCampus database synchronization was allowed to complete (overnight or otherwise confirmed). After these permission and site-assignment changes and the sync, the Standortverwaltung tab became visible and the user could perform location-management tasks (e.g., upload documents). In cases where necessary, central administration / DS directly enabled the Standortverwaltung permission in myCampus so the option appeared immediately.

IT support confirmed that the university IT team did not have access to manage Turnitin rubrics or assessment templates. The case was not resolved within IT; the requester was advised to contact the central examinations office (for example pruefungsamt@iu.org) so the examinations team — which manages Turnitin grading templates and rubric assignments — could add or attach the required rubric to the submission.

Support performed client-side checks, then investigated backend services and found the enrollment blockage originated from an incorrect capacity/business-rule state in the Cama capacity management records that the course-offer service relied on. The team corrected the capacity record in Cama to reflect the intended limits and re-synchronized the course-offer service with MyCampus. After the capacity value and business-rule state were fixed and services re-synced, enrollments and manual bookings proceeded normally.

Multiple root causes were identified and resolved across MyCampus systems. Duplicate/misimported question records were removed and canonical question records were relinked to their correct media assets; affected quizzes were republished and attempt/completion metadata was rebuilt so historical and new attempts reflected correct totals and scoring. Source-content and answer-key errors traced to upstream authoring systems were escalated to the Fachteam and Media Production; ownership and content definitions were corrected in the source systems so quiz grading matched course intent. Attempts that were stuck in an unfinalized or inconsistent state (appearing as 'Failed' or blocking retakes) were finalized or guided to finalization and associated quizzes were republished or retake windows reopened as appropriate. Separately, a MyCampus 2.0 recognition defect that prevented the course script from recognising passed quizzes (the green 'pass' indicator did not appear from certain chapters, blocking workbook submission) was fixed by development and deployed in the 2024-12-10 release; after the deployment affected users were asked to retest. After removing duplicate records, relinking missing media, rebuilding attempt/completion metadata, correcting source content, finalizing in-progress attempts, and applying the recognition fix, scoring, media display, attempt recording, completion/retake behaviour, and pass-indicator/workbook-submission flows returned to expected values.

Two distinct Microsoft-storage related upload issues were identified and resolved. One issue was an expired integration secret/password for the myCampus OneDrive connector (secret expiry in January 2025); a domain change in myCampus and renewal of the expired OneDrive integration secret restored the OneDrive connector and video uploads to the media library. A separate LIBF incident was resolved by accessing the LIBFStudy SharePoint site with the LIBFStudy account (selene-robena.illner@libfstudy.ac.uk) and uploading the videos directly to the LIBFStudy SharePoint site; the ticket was later auto-closed after no further response.

A production deployment containing the final fix was applied to the Simovative platform used by CARE and LIBF integrations. After the deployment, support verified that exam booking and enrollment pages and related overview fields rendered fully in production, and that intermittent blank/incorrect enrollment UIs and erroneous prerequisite-check results that had been blocking course/exam booking were resolved. Prior to the deployment, triage had investigated Growthbook feature-flag state, site iframe/redirect embedding and Hyperion backend ownership and performed browser-level troubleshooting (cache, VPN and account checks), but those investigations did not produce a definitive fix and the issue was cleared by the platform deployment.

The faulty deployment was rolled back to restore the previous behaviour and a code fix was developed and released in 17.10.14, which restored correct module→course population. Live performance returned to normal after the rollback; Stage continued to exhibit slower deletions until additional staging performance fixes were applied. In a related incident investigators confirmed an expired/wrong course version had been linked (causing the course to appear greyed in myCampus and enrollments to be missing in CARE) and that the Simovative bug was preventing add/delete operations on the platform. Correcting the linked course version and applying the Simovative fix (included in the release) restored course visibility and allowed enrollments to proceed.

Two frontend fixes were implemented and deployed to the myCampus web UI and MyCampus app. First, the pop-up close control (corner 'X') was changed so that closing a message correctly updated and persisted its dismissed state; previously-dismissed informational messages (including onboarding tour notices) no longer reappeared on subsequent logins. Second, the text-selection and glossary interaction was adjusted so the selection overlay no longer auto-opened in a way that blocked glossary/tooltips; an explicit small “info” icon was added next to words with stored explanations to improve discoverability and access to glossary content. These fixes were deployed to web and iOS (issue observed on iPad iOS 18.1.1). For instances that were user-specific (for example, a continuously restarting onboarding tour that could not be reproduced by support), support replaced the user’s private email with the institutional (IU) email on the account and provided local troubleshooting guidance (try an alternate browser, reset browser settings, and relax overly restrictive privacy/security settings) when the behavior appeared tied to the user’s environment.

Support confirmed the issue was related to the active profile context. The instructor accessed the attendance list by signing in through their instructor profile; once signed in via that profile the attendance list appeared and participant attendance could be recorded and saved. The case was escalated to specialists for visibility but the immediate resolution was restoring access via the correct profile session.

Engineering reproduced login failures and traced them to missing, empty, malformed, or invalid booking data from upstream booking systems (CARE/AC5 and course/lecturer booking services). Two primary failure modes were observed: an endless authentication/redirect loop, and immediate blocking errors such as STUDY_INFO_NO_ACCESS ('no booking information available') or STUDY_INFO_CANT_REACH/blank pages when booking data was unavailable or ac5Id was empty. To mitigate the user-impacting redirect loop, a backend change was deployed to the authentication/redirect logic so accounts receiving missing or malformed booking responses could complete login and reach the myCampus home (/home) instead of looping. Multiple incidents were resolved by correcting upstream booking data or provisioning: invalid Health University booking records were identified and deactivated, AC5 sync or LDAP/Okta provisioning issues were fixed, and EPOS/administration or lecturer/course-coordination teams restored proper course-booking links. Support also used account impersonation to verify whether the portal itself rendered correctly for a given account, which helped distinguish client-side/browser issues from upstream booking or provisioning failures. Standard client-side troubleshooting (clear cache/cookies, incognito, alternate browser) did not resolve issues when the root cause was missing or invalid booking data.

Investigations repeatedly identified four root causes: the frontend displayed the wrong study‑unit view, the account lacked course/unit assignments, the user was missing Care group membership, or backend entitlements/role assignments were absent or not yet synced. When only the frontend view was incorrect but backend roles and course assignments were present, switching the myCampus view restored DS/FS course visibility and lecture‑management features. Embedded services (for example Vorlesungsplan) sometimes required a separate authentication; a second sign‑in restored those embeds. The myCampus calendar was course‑specific and became visible only after assignment to at least one course; calendar write permission was a distinct entitlement and had been granted separately in multiple cases. Recurring‑event series saved as single occurrences co‑occurred with missing calendar write permission or incorrect unit/course assignment and were resolved after granting calendar write entitlement or correcting the unit/course mapping. Missing DS course bookings or enrollments were resolved by verifying and adding or updating course assignments in Care. Assigning users to Care groups such as dozent_ds (and equivalent DS instructor groups) restored Tutor Unit Wechsel and DS edit controls where applicable, but in several incidents frontline group additions (for example Dozent_DS, DS_Dozenten, ProfessorIn_DS) did not immediately restore access; those cases were escalated to the responsible department or specialist provisioning teams. Specialist provisioning granted missing DS‑specific entitlements and replicated required administrative roles; specialists verified parity by comparing the affected account to a reference account and, when applicable, changed the login to the IU email while preserving the username. Accounts with unit mapping recorded as 'N/A' were corrected to the appropriate unit (for example 'DS'), which restored DS‑only edit controls such as practice‑report editing. Hidden student or lecturer UI elements became visible after the required permissions were granted and after the next scheduled backend sync (Moodle/AC5 and role‑sync); cases where the displayed view did not change immediately were attributed to sync timing, missing assignments, or incomplete specialist provisioning. Students fully blocked from the DS instance were resolved by Study Support or enrollment teams correcting enrollment or provisioning records. When the DS/FS toggle was missing, specialists distinguished cases that required fachabteilung registration (FS‑specific supervisor profiles) from cases where the toggle was intentionally unavailable. A minority of tickets had no recorded final fix in the frontline notes; those historically required specialist entitlement changes, Care/unit reassignment, or further escalation to the owning department to complete remediation.

Support staff manually cleared the registration in the LIBF system and set the registration status to valid. The updated registration was queued for the next transfer to Pearson so external exam-provider processing could proceed.

Support removed visible phantom courses or enrolment entries from affected MyCampus profiles but confirmed those items repeatedly reappeared while canonical upstream records persisted. Investigators checked CARE enrolment records and the CARE change‑history/audit log and frequently found batch or staff‑performed enrollments, legacy/exmatriculation bookings (for example entries marked “Dereg due to open fees”), or duplicate active bookings that explained reappearance or booking conflicts. In booking incidents, MyCampus 2.0 sometimes returned an explicit “you are exmatriculated” error when a legacy/exmatriculation booking was present and could be selected among multiple copies of a study programme; booking in the old view worked in some cases because it used different booking selection rules. Incidents were resolved after the responsible upstream teams (CARE/Kursmanagement, CMaaS/IU, Course Coordination/Kursmanagement FS, local course coordinators, CareerPartner or external providers) corrected, disabled, or removed the canonical enrolment/booking records so the items were no longer repopulated on the next sync; deactivating duplicate or exmatriculation bookings cleared booking conflicts and restored MyCampus 2.0 booking functionality. In one case reprovisioning correlated with Microsoft Teams membership and removal from the Teams group stopped reappearance. A discrepancy in participant counts was traced to inclusion of past‑semester or other planning‑group students and was addressed by restricting the participant‑list view to the current semester/lecture series via its filters. The symptom of completed evaluations shown as “open” was escalated to the Minerva/evaluations team and the Exams Office because of potential exam‑registration impact. During triage, support forwarded tickets to specialist teams when appropriate, reported CARE provenance findings (change‑history/audit entries) to the responsible course managers, informed users that the IT‑Service Portal did not manage upstream canonical records, and directed them to the relevant course‑management channel; tickets were closed after confirmation that upstream records had been corrected, disabled, or duplicate bookings deactivated.

Investigations grouped incidents into two primary root causes: corrupted or stale client-side session state (browser, device, peripheral or extension interactions) and server/provider-side authentication, resource or configuration problems. Client-side incidents repeatedly resolved when sessions were opened in private/incognito windows, after switching browsers or devices, or following full browser cache and cookie clears plus a browser restart; enabling third‑party cookies produced occasional one‑time successful logins. Diagnostic HAR and browser logs identified cases where extensions or add‑ons (including ad‑blockers) injected pages into iframes or blocked authentication redirects and produced continuous loading loops; those sessions recovered when the interfering extension was disabled or when users signed in with extensions inactive (for example, in incognito). Desktop failures correlated with third‑party cleaners or antivirus (examples: CCleaner, Avast) and some users required a full OS reboot or a system update (one macOS case resolved after the OS update). One integrated‑service case (Growthbook) showed no server-side errors in Growthbook logs and was attributed to a client-side blocker; disabling the AdBlocker was recommended though no definitive fix was recorded in the ticket. A LIBF MyCampus incident reported continuous page flashing across Safari and Chrome on Mac and mobile plus non‑delivery of MFA verification emails to the institution address; the ticket recorded troubleshooting attempts but no definitive remediation. Server- and provider-side incidents were traced to OAuth2/SSO or provider errors, monitoring/instrumentation overload, or infrastructure resource exhaustion. Specific infrastructure findings and remediations included php-fpm pool saturation (max_children reached), elevated PHP CPU caused by the Datadog PHP module (deactivating the Datadog PHP module significantly reduced PHP CPU, relieved web servers, and restored self‑checks and login tests), operating‑system file‑descriptor exhaustion ('Too Many Open Files'), nginx connection drops and file‑open errors, Moodle session creation/search failures, and database transaction aborts/timeouts/locking that caused request delays or failures. Isolated client-side stuck sessions consistently recovered after clearing client state, disabling interfering extensions, or rebooting the device; broader incidents returned to normal only after backend/provider remediation and infrastructure fixes (for example, removing the Datadog PHP module and addressing php‑fpm, file‑descriptor, database and nginx stability issues). Access to staging required a valid stage account and the correct staging URL.

Support confirmed uploaded files were placed in the correct lecture/planning groups and treated two distinct root causes. For synchronization cases, the VLR (LMS content sync) service was sometimes pending; visibility and frozen bulk-mail behavior typically cleared when the pending sync completed (commonly within about an hour, occasionally by the next business day or within a few days). When required, the specialist team manually triggered synchronization for the affected course(s) or across the environment to propagate files faster, after which student visibility and mail functionality returned. For client-specific cases where content was present for instructors but not for particular students (including differences between myCampus web and the IU mobile app), Tech Support guided students through client troubleshooting — verifying account and course enrollment, collecting screenshots, testing a different browser, clearing cache/cookies, using private/incognito mode, and testing another device or network — and recorded outcomes. Where visibility issues persisted after these checks, support requested 1–2 example student accounts for investigation and escalated to the specialist team. Any upload-location or access ambiguities (notably with external lecturers) were clarified with the requester via Microsoft Teams. The behaviour was treated as transient synchronization delay or client-side rendering/caching issue rather than a platform bug.

Multiple incidents were traced to permission/enrolment mismatches, format-specific access policies, CARE group linkage issues caused by incorrect nomenclature, and client-side/session browser-state differences. Resolutions observed in the corpus included:

When support lacked direct authority to change student permissions, accounts were escalated to techsupport@iu.org or routed to the owning course‑management team (kursmanagement-[standort]@iu.org or kursmanagement-fernstudium@iu.org for users without a campus). Library enrollment requests were routed to library@iu.org. News‑module attachment visibility problems were escalated to developers; a temporary workaround copied attachment content into the news post body so students could access it. The missing mentoring 'Become a mentee' control was identified as an intentional, limited rollout during the Minerva transition rather than a permissions error.

Helpdesk/Digital Learning removed the inappropriate resit link from affected students' MyLIBF course displays. Separately, support reproduced the recertification CPD submission workflow and provided updated screenshots of the submit flow, email confirmation, payment screen (card and employer-pay options) and payment confirmation pages for documentation.

Support identified insufficient myCampus FAQ read permissions on the affected account as the cause. A specialist compared the user’s permission set with a working reference account and aligned the rights, explicitly granting FAQ read access; the same approach resolved the issue for administrator accounts. Prior user-side troubleshooting (clearing browser cache/cookies, private/incognito mode, trying other browsers) had not resolved the symptom. Permission updates required propagation time; FAQ visibility was typically restored after synchronization (commonly by the following day). In some cases the permission change process resulted in broader rights than intended; affected users reported excess permissions and specialists performed follow-up role/rights adjustments where needed.

Support determined the failure was caused by the device not trusting the enterprise TLS chain (SSL inspection/proxy or missing enterprise root CA). Technicians restored trust by importing the institution's root/intermediate CA into the Windows certificate store and browser stores and corrected the device's web‑filter/SSL‑inspection configuration on the IU laptop. After the enterprise CA was installed and the SSL‑interception settings were fixed, fulltext links on EBSCO, Springer and Google Scholar opened normally in Edge and Chrome across networks.

The usability concern was collected as a product suggestion and forwarded to the MyCampus specialist/product team. The product manager accepted the item into the product vision and added the read-tracking/mark-as-read feature request to the backlog. The team acknowledged the request and classified it as a long-term enhancement; no implementation timeline was provided in the ticket.

Investigations identified four distinct causes for the limited instructor experience and the missing supervisor option. First, accounts that lacked required CARE (Care Academy) group memberships caused missing course tools, calendar entries and restricted dashboard visibility; adding the missing CARE groups restored tools and visibility once the CARE→myCampus (AC5) synchronization completed. Administrators also synchronized backend databases and ran a manual AC5 sync in the myCampus profile to expedite propagation when immediate access was required. Second, accounts that used the wrong profile type in CARE/EPOS (employee/staff vs. lecturer) required creating or converting to the appropriate lecturer or staff profile in CARE/EPOS; correcting the profile adjusted dashboard visibility and restored access to course content, messaging and the 'Get started' options. Third, missing or incorrect course or tutor‑unit bookings in CARE (including instructors with no bookings or only a single unit) resulted in nothing or only limited course data being transferred to myCampus and caused the 'Tutor Unit wechseln' option to be absent; confirming or correcting bookings in Course Management and verifying assignments in the Dozierenden App allowed the standard sync to populate course listings and UI elements. Temporary myCampus permission adjustments were applied in some cases to let users verify access while waiting for the overnight CARE→myCampus synchronization. Fourth, the supervisor ('Betreuer') section and the option to set supervisory capacity for bachelor theses were controlled by the central examination office rather than by CARE group membership; cases where this option was missing were forwarded to the central examination office (zpa-dualesstudium@iu.org) and users were instructed to have the office enable supervisor status. Each issue was resolved by applying the corresponding corrective action and allowing the relevant synchronizations to complete.

Access was restored in many Firefox cases after removing Firefox-specific cookies and cached site data (per Mozilla guidance); after cookie/site-data removal MyCampus loaded normally. Testing in Firefox private/incognito mode also allowed access in affected sessions. Clearing general browser history alone had not resolved the issue. In some cases where cookie/cache removal did not restore authentication, users were able to access MyCampus successfully in Microsoft Edge; those incidents were forwarded to specialists for further investigation.

Developers applied a server-side correction to the user-recognition logic tied to SSD records. An initial deployment on 2025-03-14 stopped the immediate submission failures for many users and eliminated the false "not all mandatory fields have been filled in" validation errors. Follow-up fixes addressed remaining cases where applications or drafts became invisible after the error. A final verification on 2025-04-08 confirmed the students reported in the incidents could successfully submit requests. The issue manifested across browsers and was not attributable to browser plugins or simple cache/browser settings.

Support verified the user’s identity and tenant membership and confirmed the correct tenant-specific myCampus portal and login endpoint (for example distinguishing normal vs employee logins, and tenant-specific domains such as mycampus.libf.ac.uk). Support checked whether the user authenticated successfully to Okta and whether the tenant-specific myCampus app/tile was present or accessible, and reviewed account activity and authentication logs to correlate failed logins, password changes, and subsequent successful logins. When password-reset or Welcome emails were missing or undelivered, support checked inbox and spam folders and sent MyCampus password-reset links to all contact addresses on record; where multiple addresses existed, links were sent to each address and tenant guidance was communicated. For accounts that had become inactive, expired, or were temporarily blocked, support restored access by performing password resets and sending instructions so users could set new passwords; at least one user regained access after a temporary block cleared prior to using a sent reset link. In incidents where the password-reset flow itself malfunctioned, support restored the password-reset service and had users retry the reset; access was restored after the users changed their passwords via the reset links. When tenant login pages would not load or resets could not be completed, support investigated client and local-network causes (for example browser cache/cookies, local firewall or VPN effects) and collected screenshots and location details for further troubleshooting. Support noted that downstream services relying on MyCampus authentication (for example Turnitin and tenant account integrations with IU Outlook) remained inaccessible until MyCampus access was restored; Outlook integration problems required additional screenshots/location details and had no documented final fix in matched tickets. Tickets were closed after reset links were delivered and received, the reset service was restored, or the user confirmed successful access.

Support restored missing upload UI controls by addressing two distinct causes observed in reported cases. For group-specific cases in the myCampus teaching-materials area, specialists created or enabled the missing group-specific folder and activated the group's upload permission; after the folder and permission were provisioned the upload UI reappeared under 'II. Deine Lehrmaterialien'. For dashboard/ILSE video-gallery cases, a previously disabled course/dashboard configuration setting that hid upload buttons was identified and enabled; after saving the setting the missing buttons reappeared and upload functionality worked. In all cases the change was applied at the course or course-group level and the instructor confirmed the upload controls were restored.

Specialist staff checked the course enrollment records and confirmed that no students were enrolled in the lecture series. The instructor was informed that this was not an IT-side problem and was advised to contact their academic/administrative coordinator to address enrollment timing; the ticket was closed after providing this information.

Course Feed membership and removal incidents were investigated across several causes and remediations were applied according to observed root causes. Normal behaviour and support boundaries: students were ordinarily able to remove themselves via the Course Feed self‑unsubscribe option; support staff did not have access to student accounts and could not add students on behalf of tutors or academic contacts. Enrollment-reset defect: a recurring defect that reset Course Feed enrollment when modules were transferred or marked inactive prevented affected students from successfully self‑unsubscribing, caused continued Course Feed email notifications, and left users in Teams/Office365 groups; that defect generated high ticket volumes and was escalated to WebCore/BE Learn and migration teams for deeper inspection. Channel/connectivity and chat symptoms: some incidents presented as a channel connectivity error (“We can't find that channel due to connectivity issues. Please try again later.”) or as users joining online sessions but being unable to view chat; those cases were handled as access/membership problems and routed to the appropriate learning‑experience or platform teams because support lacked direct access to student accounts. Automation and synchronization: separate incidents of unexpected membership changes, including repeated owner removals, were traced to an automated synchronisation process (LogicApps automation account) that synchronised MyCampus Course Feed membership with Office365/Azure groups; audit logs showed add/remove actions from that automation. Remediations performed included changes to synchronization rules, revisions to automation logic, and a review of Office365/Azure group membership flow and ownership. Single‑feed limitation and channel enrolment logic: the Course Feed’s single‑feed limitation (after legacy forum removal) prevented creation of additional student‑only channels in large courses; temporary workarounds were provided while forum removal and channel‑limitation issues were handled separately. Automated enrolment into teacher/exchange channels was traced to synchronisation using Teaching Formats/CPC roster data and Course Feed group logic; responsibility and ownership of that enrolment flow were clarified and assigned to product owners. Incidents with no technical fix recorded were routed to the Learning & Teaching Experience service portal for further investigation.

Multiple, recurring root causes explained the Application Manager failures, missing items and access failures and were resolved using targeted fixes. Incorrect or incorrectly linked CARE application records (for example records pointing to the wrong degree programme) produced blocking errors or absent items; fixing CARE application entries and their linkages restored Application Manager actions and menu items. SSD had sometimes merged two CARE applications into a single SSD record; MyCampus 2.0 applied degree-level visibility filters (Bachelor vs Master) to the application dropdown, which hid items that still existed in CARE; affected students were informed that the displayed menu reflected the merged SSD entry and degree-level visibility rules while records were reconciled. A synchronization bug in the CARE→MyCampus process produced inconsistent or incomplete linkability (including cases where clicking a user in the myCampus user list did not open Antragsverwaltung); the CARE/synchronization specialist team fixed the sync bug and support confirmed access restoration. Some application links and Antragsverwaltung items had been implemented or configured in CARE instead of in MyCampus; those tickets were reassigned to the CARE component and fixed on the CARE side. A small class of UI-only defects in MyCampus 2.0 form-field configuration produced incorrect dropdown labels or options (for example the Abschlussarbeit form’s language dropdown); the form configuration values were corrected and deployed to production. While underlying CARE/SSD records were reconciled or synchronization fixes were applied, support temporarily restored visibility or provided direct application URLs and impersonated screenshots so students could meet urgent deadlines. After CARE/SSD record corrections, synchronization fixes, or MyCampus form-configuration fixes were applied and deployed, Application Manager actions and menu visibility returned to expected behaviour.

Specialist teams identified the affected accounts as belonging to teachout cohorts or to study programs that were not included in the MyCampus 2.0 rollout and confirmed this behaviour was intentional rather than a platform fault. Migration to MyCampus 2.0 was performed per study program (not per individual user), so students whose programs remained on the classic platform — including users with active bookings such as Mitarbeiterkurse and Upskilling — continued to see MyCampus classic; this explained why some users could not access exams (access depended on student status tied to their program/bookings). The Payments feature had not been rolled out to OI/EU teachout cohorts (FS business unit), so Payments controls were absent for those students; the Payments rollout for these cohorts had been deprioritized following the Minerva and OI/EU teachouts. A KS-wide issue that caused the MyCampus dashboard 'Help & Contact' page to render blank for remaining teachout users was diagnosed by the specialist team and fixed as part of the MyCampus 2.0 migration work. Affected students were informed of their program-specific migration status and the reasons for missing functionality; no configuration changes were applied to migrate or enable MyCampus 2.0 or Payments for teachout cohorts as part of these incident resolutions.

Course visibility issues were resolved by two distinct fixes depending on root cause. In cases where an instructor's MyCampus account mapping was incorrect, visibility was restored by updating the user's external-address (account‑mapping) while leaving the existing password unchanged; the user continued to authenticate with their username. In other incidents the root cause was the course record itself (for example, semester/Q4 courses flagged as inactive or bookings assigned to the wrong course instance); those cases were investigated and corrected by the course‑management/booking specialist (fachteam), after which changes propagated via the overnight synchronization. Confusion between similarly named course instances (programme/language variants) was a frequent contributing factor. Support teams without course‑booking privileges could not see or alter enrollments, so corrections to bookings/enrollment status required action from the course management/booking team or specialist.

Access and functionality were restored by a combination of client-side remedies and service-side fixes depending on the symptom. For rendering and display failures (including 'translation problem', 'page not found', and missing lecture-planning or virtual-room links), support cleared browser cookies and cache, restarted or tested an alternative browser, and opened the attendance tool with the full session time-range rather than a single-hour slice; after these actions the attendance form and lecture-planning pages rendered correctly and users could record attendance. For navigation/redirect loops where links on the attendance screen returned users to the same page, the specialist team applied a service-side fix and users then cleared browser cache/cookies; after the service fix and cache refresh the navigation loop no longer occurred. For isolated backend connection failures that returned 'Allgemeiner Fehler bei der Verbindung zu CARE', users retried the attendance action and the operation completed successfully, indicating a transient connection error to the CARE service.

The cause was traced to legacy pilot/opt-in state and backend redirect/session mappings created during Course-UI pilot migrations. Support removed the legacy opt-in/pilot flag from affected accounts and cleared the server-side redirect/session entries for those users; when a course-level pilot assignment was responsible, disabling that course-level pilot mapping prevented the redirect. After those backend flags and mappings were cleared the affected users remained on mycampus.iu.org and no longer landed on the Classic site.

Investigations identified two recurring causes for students not seeing course materials or course interfaces in myCampus. First, incorrect authoritative mappings in CARE (wrong course‑instance identifiers, Standort/section assignments, or student‑to‑section enrolments) prevented myCampus from exposing documents/videos and tutor/instructor visibility; the CARE UI could appear correct while underlying attributes were wrong. These incidents produced no standard error codes and sometimes affected only specific study‑format cohorts. In each case the issue was resolved after the upstream CARE or mystudium attributes were corrected and a forced synchronization to myCampus was performed; simple resynchronisations without first fixing upstream mappings did not restore visibility. Support frequently routed requests to campus course‑management teams (kursmanagement-[standort]@iu.org or kursmanagement‑fernstudium@iu.org) because fixes were made in CARE/mystudium. Second, some incidents were caused by missing or improperly linked module components within myCampus after a course update (for example a module's additional‑learning‑materials/order interface not integrated), which produced blank pages or absent order forms for students. Those cases required changes in myCampus (handled by the Fachteam/product team) to restore the module linkage; after the portal integration was fixed the order interface and other course components became visible. In all observed incidents, no consistent platform error code was available to indicate the root cause.

Support resolved reports by addressing a browser-side rendering/cache problem. Cases were fixed when users cleared browser cache and cookies or opened myCampus in a different browser profile (incognito) or a different browser entirely; in one case the user could access the correct timetable via Safari on an iPhone. The tickets noted a consistent visual indicator (a black border when the module rendered correctly) that helped confirm a client-side layout state rather than a backend fault.

Missing or changed events were recovered by re-exporting the calendar from myCampus and re-importing it into Outlook because the original export had been a static (one-off) ICS file. Support documented that myCampus provided iCal/ICS exports that were not editable in Outlook — events imported or subscribed from the ICS feed could not be edited (titles, owners or notes had to be changed in myCampus). There was no in-product workaround to make the imported events editable; periodic manual re-export/re-import was therefore used to synchronise later changes. Support also recommended contacting the Lecturer & Course Coordination (LCC) team for course-planning assistance or to request an alternative export/process if editable copies were required.

Investigations identified two root causes that produced the same visible booking failures. First, some student accounts retained StudyProgress ownership records that did not match their active programme (for example accounts owned by EPOS or imported into EPOS as an 'only profile' despite not being FS students). That mismatch triggered CARE's booking-avoidance/authorization logic and led to either the booking button being hidden with the 'Oops: Course and Module booking moved to a new site...' message or the CARE iframe returning an authorization failure ('the page cannot determine if the user should be able to do this'). Second, certain booking imports were missing PIM study-plan records so the booking import could not populate modules and ECTS, producing an empty page showing 0 ECTS. The incidents were resolved by correcting StudyProgress ownership to match the students' active programme (removing incorrect EPOS ownership where present) and re-importing the missing study-plan data into PIM. After ownership and PIM study-plan data were corrected and the booking import re-ran, the import completed successfully and the course booking interface displayed correct ECTS and available modules (booking buttons became available). Diagnostics noted the booking-avoidance behavior did not always produce server-side error logs and that some failures only reproduced under impersonation; the hidden booking button with the specific 'Oops' message and the CARE iframe authorization error were reliable triage indicators.

The request was escalated to the myCampus specialist team and ownership for the accessibility topic was assigned to the myCampus product lead (Tina Schattner). A coordination meeting was scheduled to review the two supplied course pages and the Silta "Kurzprüfung" checklist so the specialist team could identify which myCampus defaults or templates needed changing to allow editable alt texts and other checklist items.

When users lacked expected course-administration controls and Turnitin archive or grade-entry access, support actions fell into two categories. For technical/permission gaps, support restored functionality by granting permanent myCampus admin permissions matched to an existing admin profile (configuration aligned to the account used by nuria-badia-comas), which reinstated course-deletion and remove-students rights and restored Turnitin archive view. Support observed that provisioning/synchronisation could delay visibility of newly granted admin controls and that changes often became visible the following day; in at least one transient case a user regained admin access after re-login without further changes. Separately, specialists diagnosed a capability-level software bug that blocked block/iubh_tutor_grades:viewgrades during early grade publication; that required developer changes and was escalated to specialist/developer teams. In other incidents where no technical error was present, staff determined the cause was administrative/authorization (not a platform bug) and advised escalation to the central examinations office (ZPA) — the ZPA contact used in cases was zpa-dualesstudium@iu.org — and referred course-booking matters to the Local Course Coordinator.

Investigations found multiple distinct failure modes that caused missing MNRs or suppression/errors for the student ID option in myCampus. 1) EPOS booking mismatch: some applicant bookings created by EPOS had been ignored and a new unlinked booking existed in CARE, so the CARE record lacked a validated EPOS-format matriculation number (MNR). Support manually inserted the validated EPOS-format MNR into the student's CARE record; after the CARE→myCampus replication run (observed after ~24 hours) the MNR appeared in myCampus. 2) Temporary matriculation metadata: CARE booking metadata for pathway (Vorprogramme) records — commonly returning student_grad = TEMPORARY_MATRICULATED_UNDER_RESERVE or statuses such as 'Vorprogramme und Dokumente fehlen' — had been treated as not regularly matriculated, causing the student ID option to be suppressed by myCampus display/eligibility rules. Affected records and their characteristics were recorded for follow-up remediation of booking statuses and the display/eligibility logic. 3) Expired study period: an additional mode was identified where the student's booking study period (Regelstudienzeit) had expired; this caused myCampus to suppress the student ID or to show an error when the student ID button was clicked. That finding was recorded and the case was escalated to student-services/booking remediation for status correction. In all cases, updates to CARE metadata were observed to replicate to myCampus within approximately 24 hours.

The root cause was a mismatch between the student's booking/cohort location and the location assigned to the community/document. Resolution actions included updating community/document configuration to assign the correct campus/location (for example assigning the Ulm location) and correcting cohort→location mappings in the backend where they were inconsistent. In cases requiring vendor support, Simovative diagnosed and corrected community/document location assignments. After the location assignments and mapping corrections were applied, the previously missing student ID/immatriculation/enrollment documents and the document selection/download functionality became visible again in MyCampus, MyStudium and LearnApp. Affected integrations included CampusWEB, CARE and the document-generation flows.

Support removed obsolete or retired application content from the MyCampus Application Management UI so the interface no longer presented items that were no longer valid. Removals included an outdated PDF link (CampusChangetoBadHonnefInformation.pdf) from the MSE Application Management header, the deprecated "Pflegeberater" certificate option from MyCampus 2.0 Antragsverwaltung (removal confirmed 2024-09-24), and a now-unneeded "Deregistration form" link in the MSE Application Management area (deleted by support after coordination with the MyCampus team and CARE; requester verified). No runtime errors were involved; the removals prevented further invalid application attempts and reduced related user confusion and administrative workload.

Support provisioned the Deskbird application to affected users (account/app assignment) and confirmed that Deskbird sign-in failures were resolved after provisioning. For visual differences and missing pre-configured courses, support explained the layout reflected the new myCampus 2.0 UI and confirmed users' access; no system fault was found for the UI change itself. For onboarding checklists that remained at 0%, the ticket was escalated to the product team (Product Fruits) and investigators reviewed user actions; no reproducible technical bug in MyCampus was found. The product team determined the checklist entries had not registered because items were likely not fully completed/clicked by the user and that no server-side change was required. Users were informed of the required completion behavior and the case was closed once the user acknowledged the result.

The user's display name was updated in the MyCampus system to the correct value (Anuja Hariharan). Support notified the user to verify the change and confirmed the update internally before closing the ticket.

Support determined these incidents were caused by missing course bookings or official Tutor role assignments that were managed by Course Management / LCC and recorded in CARE. Support verified account synchronization and sign‑in (including Microsoft Teams linkage) and confirmed no account‑level or system errors; the visible symptoms (empty 'My teaching' lists, inability to access course materials or exam guides, 'unable to self‑enroll' messages, missing tutor roles in the FS view, and absent grade‑publication/dashboard tiles) corresponded to courses or roles not being booked. Support escalated to the specialist team or re‑triggered/followed up enrollment and role requests with Course Management/LCC; Course Management then enrolled users in CARE and assigned the official Tutor role, after which MyCampus listings and dashboard tiles populated. Tickets were retained/closed as informational after recording the escalation and advising users to request bookings/role assignments via the Course Management/LCC service portal.

Support and specialist teams investigated multiple root causes and applied component-specific remedies. DevOps-related changes to the Classic SSD upload service were reverted or corrected, which restored standard web upload functionality. Restoring a backend synchronization service recovered upload capability on course dashboards and MyCampus. Several in‑browser upload UIs that would not load were traced to blocked browser media permissions (camera/microphone/image+audio); granting the required permissions allowed those UIs to function. Video gallery and recording upload incidents were handled variably: some cases were escalated to AI Media Service Support, some workflow/formatting or persistent-stall incidents (including a recurring ~15 MB stall) were forwarded to the teaching‑formats team, and at least one media-recording/form-validation case (form reported “all fields must be filled” despite completed fields) was forwarded to Media Production with no portal-side technical remediation recorded. A reproducible case where uploaded folder/files briefly appeared and were immediately removed was observed during reproduction and required specialist backend/course-folder retention follow-up; no immediate portal-side fix was documented. Several reports traced to client or server cache/cookie problems or to specific gateway/web-node issues (for example DLBPGWPE01_E) and required additional specialist follow-up outside the standard portal workflow. Administrative or examination-related upload matters were forwarded to the central examination office. Multiple tickets were escalated or redirected to specialist teams and, in some cases, users were advised to open or recreate cases in the responsible specialist portals.

Investigations first validated local myCampus UI permissions, profile records and sync logs and confirmed when sign‑in problems were due to unusable passwords; those accounts were restored after a MyCampus password reset via the user’s IU‑Mail. When users could sign in but items remained missing, the root causes were upstream: missing, incorrect or inconsistent enrollment/booking/membership records in CARE or upstream course‑management feeds. Symptoms included courses showing only in course bundles or in external apps while lacking backend bookings, students not listed as participants in course management, missing gradebook entries, or the enroll/unenroll button absent in Care Community (production) while present in Stage. For example, the BAHP Anerkennungspraktikum (DLBHPPPHP) was visible in the bundle/UI but had no backend booking — it did not appear under the Care Backoffice “Vorlesung” view, affected students were not participants in course management, and the enroll button was missing in Care Community until backend records and feeds were corrected. Affected cases were escalated to the specialist/course‑management team, who corrected source‑of‑truth records in CARE or the course‑management system (examples: selecting and saving program specializations on bookings, removing enrollments on retired codes and enrolling into restarted courses, cleaning up improper manual entries or role assignments, and correcting identity data). Relevant repositories and feeds (for example Better Care / CARE / course‑management feeds) were reprocessed; after the upstream records were fixed and feeds reprocessed, myCampus and Care Community retrieved the bookings/responsibilities and course or specialization visibility, enroll buttons and gradebook entries were restored. It was noted that some external applications continued to show courses while myCampus did not because they relied on different data feeds or environments (Stage vs Production).

A specialist located the specific course records attached to the user account and changed their visibility status to hidden/inactive for that user. After the visibility flags were updated the courses disappeared from the user's dashboard and the report was closed as resolved.

Specialists identified two main root causes and added clarifications about platform limitations. For missing DS‑Unit tiles, absent enrolment/select options and Study‑Guide impersonation failures, teams confirmed the affected accounts lacked required Care/role permissions (examples: Dozent, DS‑Dozenten, Dozent‑DS, Dozent‑FS). Granting the appropriate Care/role permissions and restoring Study‑Guide impersonation/self‑enrol rights resolved those cases after the platform backend synchronization window elapsed and the DS‑Unit tiles and enrolment options appeared. When course catalog or unit content was missing because the wrong record was associated, support changed the unit assigned to the affected record and the Vorlesungsverzeichnis became visible after synchronization. When support 'log in as' impersonation showed MyCampus Classic and did not load MyCampus 2 micro‑frontends (hiding Payments / My Finances), cases were escalated to the myCampus team; where viewing finance pages as a student was required, teams granted the EPOS impersonation role in production (with the known audit‑log consequence that actions appear as the impersonated student). Support clarified that myCampus 2 did not provide a full or reliably equivalent student‑impersonation view compared with myCampus Classic; as a result, teams advised using dedicated student test accounts or restored Study‑Guide impersonation accounts to obtain a true student perspective when required. Separately, when a Jira link to contact the myCampus Content Team landed on the Jira start/home page, support confirmed this behavior was caused by insufficient Jira create permissions for the target project rather than by myCampus permissions and informed the reporter that Jira project permissions were required to create the request. All permission and unit‑assignment changes required backend synchronization time to propagate before the UI reflected the fixes.