Access, visibility and incorrect‑content incidents were resolved by restoring correct account context, entitlements, site/location assignments and cross‑system ownership to canonical reference records, or by applying developer/vendor fixes when configuration alignment did not correct symptoms. Key resolution outcomes included:

Persistent anomalies that did not respond to entitlement, configuration or environment fixes were escalated to development, middleware or vendors for follow‑up; reproducible functional regressions were documented with reproduction steps and observed workarounds to expedite triage and fixes.

Duplicate, missing, or incorrect CARE profiles and bookings were remediated by consolidating authoritative records and removing or hiding extraneous ones so workflows and downstream systems referenced the intended profile or booking. Where possible, CARE’s duplikate_merge (care-admin merge) was used to merge duplicate profiles and exam/booking records into the primary profile after reconciling separate auth0/Okta/Azure AD credentials; merges were controlled by a high‑privilege role and required business approval. When merges were blocked or irreversible, extraneous profiles and duplicate bookings were deactivated, hidden from community/course management, deleted, or archived downstream. Authentication artifacts were consolidated or re‑associated so login and permissions issues were removed; merges previously blocked by SSO/login state were retried after SSO fixes.

Academic history and semester assignments tied to inactive duplicates were moved into the correct active booking or inactive bookings were removed so automatic enrollment and Immatrikulieren visibility were restored. Booking attributes were corrected (cohort codes, exam‑center/presence, login‑name/site‑location and stored email attributes) so Moodle, attendance management, grade entry and lecture plan permissions behaved as expected. Misclassified persons and orphan instructor profiles were corrected, replaced, or disabled and private-email/.ext-account mappings were reconciled so teaching visibility, enrollment and access to SharePoint/student documents were restored to the authoritative profile.

Cases where a CARE profile or cross‑system link was missing were resolved by establishing the authoritative CARE profile and reconnecting identifiers across systems: manual linking or recreation of the CARE profile when required, re‑triggering or repairing Transfer2EPOS transfers, and coordinating with Salesforce owners so EPOS/CARE/Salesforce records referenced the same customer identifier. Where tickets recorded no single technical fix, the outcome was achieved by creating or linking the authoritative CARE record and aligning identifier mappings so downstream automation accepted the profile.

Conflicting matriculation numbers (MNR) were resolved by identifying accidental duplicate MNR records, consolidating them into the authoritative MNR in CARE, and updating EPOS/myCampus and student‑context backends to reference that MNR; underlying CARE process bugs that created duplicate MNRs were corrected and synchronization between CARE and EPOS/myCampus was restored to prevent recurrence. Investigations repeatedly identified integration and mapping causes — Transfer2EPOS (Salesforce→EPOS/CARE) failures, stale identifier mappings after on‑prem migrations, incorrect CU/academy‑id records, and SOAP/SOS/AMOS onboarding batch logic (a student onboarding run had created many duplicate UPS bookings and stored IU‑specific emails). Remediations therefore included cleaning duplicate bookings, correcting stored email attributes on bookings and profiles, realigning mapping keys between Simovative/CARE and customer identifiers, and adjusting onboarding integration and batch logic.

Course duplication originating in Curriculum was resolved via product releases (v17.12.14, v17.13.7, v17.14). Reporting errors were fixed by changing SQL/joins in the Simovative/academyFIVE layer to join on CARE’s authoritative booking identifiers and to exclude inactive or deleted bookings; corrected reports were republished so downstream automation consumed intended active booking data.

Multiple CARE incidents were traced to corrupted per‑user browser/session state, a Chromium/Chrome rendering bug, overloaded browser profiles with many open menu items, occasional service outages, and one Okta authentication migration that later resolved recurring login/lockout behavior. Reported fixes and observations that restored functionality in many cases included: - Clearing site cookies and cached web content, performing a hard reload (Ctrl+F5), logging out and back in, or opening CARE in an incognito/private window. - Switching from Chromium/Chrome to Firefox avoided several message‑editor and template‑selection failures attributed to a Chromium rendering issue. - Reducing browser zoom revealed off‑screen UI elements in at least one case and restored access. - Closing all open menu items in an overloaded user session/profile restored that profile and allowed login. - A Firefox‑only “400 BAD REQUEST” case required clearing site cookies/cache, fully exiting Firefox, and removing specific files from the user’s Firefox profile folder (%APPDATA%\Mozilla\Firefox\Profiles) to restore access. - Intermittent “access denied” messages and failed Salesforce→Care transfers cleared after a forced reload once service availability returned. - In one incident the problem did not reproduce when an administrator logged into the affected accounts, indicating the fault was tied to the individual user’s session/profile rather than a global permission change. - A previously used workaround (saving email as a draft and reopening) stopped working in some reports because drafts were not being saved; in those cases clearing cache/cookies and using Firefox restored layout selection. A separate, reproducible symptom was reported where email bodies were being truncated (approximately two‑thirds missing) when saving or sending templates; standard browser fixes and template-copying workarounds were attempted but no definitive system fix was recorded and the Salesforce Marketing Cloud integration was implicated. Operational note: requests for new email layouts still required onCampus Operations Team coordination with Marketing.

Multiple CARE/DokGen investigations identified several overlapping, independent causes rather than a single uniform defect. Resolved items and findings included: - A CARE/DokGen template replacement (vendor-supplied 'SIMO_debug_9692 - Duales MyStudium') was deployed and restored correct Hochschulsemester/Fachsemester display for a MyStudium case where quarter-starter semester values were wrong. - The specialist team corrected DokGen/CARE document-generation configuration that had produced blank Overview of Grades PDFs; PDF export/printing resumed after the configuration fix. - Simovative (vendor) confirmed that the DS programme document template enforced a fixed output start-date period (01.04), causing Immatrikulationsbescheinigungen and related semester displays to show 01.04 even when students started on 01.01; this vendor-side template behaviour was recorded and communicated. - Multiple certificate cases showing incorrect 'Regelstudienzeit' for students transferred into CSE cohorts were reproduced and escalated to the specialist team and the vendor for further investigation. - Investigations repeatedly observed DokGen selecting incorrect date fields (for example using 'Freigabedatum' instead of 'Datum') and reading booking/cancellation dates from the wrong UI tab (e.g., reading 'gekündigt am' from the 'Weitere' tab). - DokGen failed in some cases to exclude Praxisberichte courses (PraxP1‑B…PraxP7‑B) from certificates/transcripts. - Curriculum-change processes that created new bookings or remapped bookings caused Werdegang and cohort entries to be treated as new programmes; this produced incorrect semester counts and incorrect 'Regelstudienzeit' on certificates, and revealed that the existing grade/credit transfer mechanism ('Leistungen anerkennen' / Prüfungsleistung) did not support transferring grades between cohorts inside the same booking. Apart from the template replacement and the specialist-team configuration fix and the vendor confirmation about DS templates, no single code‑level remediation was documented; other issues were forwarded to Simovative and the specialist team for further remediation and investigation.

Simovative released a vendor fix that restored the previous multi-filter OR-like behavior for timetable filters; the fix was included in CARE releases after v17.21.6 and was present in the customer's Live environment on v17.21.16. Support validated the timetable overlay behavior in Live (including cross-browser checks such as Firefox) and asked users to retest until the expected overlay of Instructor and Planning Group filters was confirmed. A related regression was identified where clearing Year/Association or Semester filters made historical course bookings disappear from a student's 'Vorlesungen' / 'booked events in profile' view (permanent courses were particularly affected). That issue was submitted to Simovative and, pending a vendor patch, Support provided a temporary workaround: apply Semester + Year filters to surface historical course bookings for the specified term. The profile-bookings regression remained tracked with the vendor for a permanent fix.

Missing or blocked AGB versions were resolved by preparing and importing the required contract versions into CARE and by enabling approver approvals and user permissions. For the INTL (CSE) case, the approver (Christoph Jaecks) approved the change and the named user (Andrea Ulbrich) was enabled to create AGB v1.1cse in Production CARE; she created the version and confirmed it was ready. For Team Theia requests, new AGBs for DWB (1.1DWB) and QCG (3.6) were prepared, integrated into Production CARE, verified ready for use, and requesters were informed. CARE stage blockers were removed so Theia could add CARE IDs to Better Care and the business team could create and approve an example contract on stage prior to rollout; stakeholders also agreed a versioning approach for the INTL contract. Synchronization concerns between CARE stage, CARE production and Salesforce non‑prod were noted during triage. Where reporters lacked Jira access or closure permissions, support closed related tickets after confirming the AGBs were available. Separately, a data-model gap preventing identification of students in a paid-extension (required for reminder emails and automation) was escalated to the specialist team and handed over to IU DevOps: the requester created a DevOps ticket, provided the bot user, and the front-end ticket was closed as duplicate/test while implementation work moved to DevOps.

The request was forwarded to the specialist/vendor team (Simovative). A new field supporting study-program-dependent pricing for SSK combinations was implemented in CARE and made editable, enabling pricing to be maintained per study program.

A consolidated set of targeted fixes and reconciliations restored correct CARE reporting, exports and downstream integrations and addressed a Stage availability investigation for an attendance report. Key outcomes included:

These actions restored correct graduate lists and event scoping, exposed required partner and correspondence contact fields in exports, prevented correlated‑subquery cardinality errors, corrected intake program encodings for ONLINE‑INT rows so dashboards regained program granularity, ensured DS Care exports excluded drafts and used submission dates for ordering, mitigated intermittent export/download failures affecting automated consumers, repaired ad‑hoc queries to run in CARE, corrected reconciliation logic so Power BI no longer reported unexplained 'unknown' diffs when sources aligned, rebuilt undocumented extracts for BigQuery where necessary, and remediated production sync/cache issues so backend APIs served authoritative demographic values. A Stage‑specific attendance report availability issue was investigated (user guidance and Stage configuration change were recorded) but no final fix was logged in that ticket.

Support restored CARE access by identifying the user's true CARE username (common formats: surname.lastname or short student formats) and confirming the correct authentication path. Support clarified that CARE required the CARE username rather than an IU email after a temporary email-as-username option was removed. When browser password managers (including 1Password) autofilled incorrect credentials, support disabled or corrected the autofill entry or had users re-enter credentials; fixing autofill resolved many cases. Support corrected or added IU email addresses on CARE/Study/MA profiles and retriggered password-reset emails when email delivery had blocked access; when Stage 'forgot password' emails were unreliable, access was restored by resetting the password in the primary CARE system and using those credentials on care-stage or by using the primary system's temporary password. When SafeLink or the self-service reset rejected compliant passwords, admins generated temporary passwords or used admin-driven authentication. Support enabled or whitelisted disabled accounts, re-authenticated users to the correct myCampus/CARE account when multiple linked accounts existed, and used the Okta dashboard alternative-authentication path for SSO rejections caused by IU-email usage. When users encountered the German campus error, support changed the location selector or granted missing location permissions to restore campus access. For Stage vs Live issues, support confirmed that CARE Stage was synchronized from production and that valid Live credentials were sometimes rejected on Stage until the scheduled provisioning sync completed; permission and role changes normally propagated within minutes. In one incident, the Care Stage portal login failure was traced to an AWS-side infrastructure issue and was resolved after an external engineer applied an AWS-side fix.

Incidents resolved several root causes across data, configuration, generator logic and transient service availability. In some cases a general CARE service outage prevented frontend generation and MyCampus application‑management actions; once the CARE service recovered, certificate generation resumed and previously empty files were produced correctly. For data and configuration faults, CARE booking/Zuordnung and Werdegang entries were corrected: duplicate or applicant DS bookings were removed or restored, missing semesters and study‑end (Regelstudienzeit) entries were populated, and student‑group / planning‑group assignments were fixed so historical enrolments, grades and correct DS/FS template selection became visible. DokGen/Simovative and the OnCampus Care generator mappings and templates were corrected so language/format options and correct templates were produced; documents that had been left in draft without AC‑Five verification IDs were regenerated after generator fixes so completed certificates included verification IDs. CARE/DokGen eligibility and enrollment/status mappings that had incorrectly marked students as participants or excluded them were fixed so certificate generation and grade entry proceeded. DMSD and enrollment issues caused by product/requirement‑format mismatches were resolved by aligning requirement/product configuration with the updated DMSD format and by changing certificate evaluation logic to consolidate overlapping bookings and compute semester counts from consolidated booking/status information. Authorization failures (including error 1020) were addressed by extending the booking‑status query used by the Immatrikulationsbescheinigung, and a frontend/backend mismatch where a “printable semesters” SQL query exposed semesters the back office could not generate was fixed by aligning the frontend query with backend generation logic. Affected users were reprocessed where necessary; systems addressed included CARE (booking/Zuordnung, Werdegang), DokGen/Simovative, the OnCampus Care document generator, DMSD, Mystudium/myCampus and MC 2.0.

Multiple distinct causes were identified and resolved across related incidents:

Each incident was resolved with the specific remediation above (UI setting clearance, vendor patch, specialist fix, manual data cleanup, or service configuration change) and verified with the reporting users or owners.

A consolidated set of template, data‑mapping and business‑rule fixes resolved selection, eligibility, rendering and storage defects across DokGen, CARE documents and contract templates, Care Community DS generator, Curricula Management, Simovative and EPOS. Key outcomes included:

These changes removed template visibility leakage between units, restored missing signatory/name and contact fields, corrected exmatriculation defaulting and date handling, enabled partner‑specific ToR requirements (LIBF) and multi‑specialization rendering, harmonised certificate‑generation logic across systems (including fixing selection-context eligibility where module vs course selection previously allowed incorrect generation), and addressed template XML syntax failures that previously blocked generation. Where generation was suppressed by operational regressions, affected cases were either re-enabled by the specialist team or escalated for specialist resolution; manual document creation remained a temporary workaround in some incidents.

A combined set of configuration fixes, mapping corrections, vendor updates and data reconciliation reconciled grade display, aggregation, rounding and document outputs across CARE, Simovative/academyFIVE, MyStudies/Modulnotenskript, Notenblatt, DokGen/ToR, Moodle and EPOS. Key actions and outcomes included:

Support first verified requester identity and any required manager approvals before restoring CARE/EPOS access. When accounts were missing or credentials failed, administrators provisioned accounts or confirmed existing accounts and delivered credential information or recovery via Safe Link or guided password self‑service; in several cases support confirmed the EPOS URL and returned existing username and academy‑ID details. Account creation was repeatedly blocked when a reference user was not supplied, and support documented that provisioning could not proceed until an appropriate reference profile was identified.

Missing or restricted CARE features were restored by comparing the requester to a known‑good reference user (avoiding full admin templates) and adding the specific named permissions, permission‑set alignments, folder/view memberships and group roles found on the reference profile. Commonly added named permissions included prufungsmanagement and kursmanagement (and DS/INT for MSE/CSE activities), layouts and dokgen for document/layout functionality, and explicit report‑run or report‑approve rights where reports were absent. When the symptom was inability to view individual exam performance details (double‑clicks not opening), support assigned the requester to the Prufungsamt group when policy allowed — membership in the Prufungsamt group was required to inherit rights to view Pruefungsleistungen details and such membership was restricted to Prüfungsamt staff.

Care SharePoint access was fixed by mirroring reference‑user SharePoint permissions when page access was the symptom. When location scope caused restricted visibility, site/location scope was adjusted to match the reference user (for example 'alle Standorte'); switching the UI to a single location was sometimes used diagnostically. Datasource‑ and report‑level permissions were applied by specialist teams when required and some report requests were routed to those specialists. Group and role gaps were corrected by adding appropriate academyFIVE/role groups and adjusting group permissions; commonly added groups included autoren, aktive-autoren, servicecenter-agents, studienberatung, berichte, studentensekretariat, antragsmanagement and cp-operations-manager. Where course visibility depended on student‑record type, profiles were changed to the 'Care' profile and transfers to Moses were triggered after role assignment if needed. Duplicate or conflicting accounts were consolidated and users were advised which identity to use.

SSO/login failures and missing app access were resolved by re-adding the CARE application to users' Okta dashboards or correcting application assignments; after SSO fixes, folder and application permissions were sometimes realigned to match the reference user. Permission changes typically propagated within 5–10 minutes (occasionally up to ~30); client actions that surfaced changes included sign out/sign in, using 'Show full menu', menu refresh, reloading the menu/tree and clearing the browser cache. Support documented naming/listing discrepancies with Fachteams and opened separate permission requests when account configurations lacked required rights (for example MyStudium‑Care). Support sometimes granted temporary matched rights and left tickets open for user confirmation; confirmed restorations (for example previously missing tabs, downloads, locations or Room View entries) were recorded.

Issues requiring deeper changes were escalated: EPOS/Better Care applied rollbacks or fixes for deployment regressions, Fachteams applied backend fixes for systemic connection errors to CARE, and the Better Care Team handled requests affecting locked/read‑only fields where AC‑5 IDs and sufficient employee/student identifiers were required. Administrators checked Workday/identity records for dual‑status (employee+student) before granting exam‑sensitive permissions; in dual‑status cases exam‑management or Prüfungsamt exposures were withheld unless explicit manager approval and, where required by policy risk, review by the organisation's risk/identity board occurred. Document‑print problems (for example Studiprofil > Daten > 'Dokument drucken' and missing ToR types) were resolved by matching the reference‑user document permissions (including dokgen/layouts), allowing propagation time and confirming functionality with the requester.

Support identified two distinct root causes and applied targeted remediation. First, a scheduled Simovative/Rundeck job named "Send Email - Nanodegrees" was dispatching multiple certificate-related templates (Nano Degree, Diploma, Career Path) and inadvertently triggered the UPS certificate template; automated sends for the UPS template were stopped while the underlying text templates were preserved. Second, an accidental overwrite of a CARE configuration setting during a configuration change caused student-targeted and legacy emails to be routed to incorrect recipients (including staff and external applicants); the CARE configuration state was restored, affected recipients were notified, and downstream teams (StudKomm/cards, UPS, Salesforce/Careerpartner, Workflows/Skype) were engaged to correct workflow state and schedules. Investigations covered CARE, the email gateway, and downstream integrations and found no evidence of account reassignment, elevated permissions, or a security breach. Support also corrected at least one follow-up/explanatory email that had been misaddressed during remediation.

In parallel, teams documented operational context and next steps for the automation: the Rundeck job was reviewed and is currently inactive, and a request was raised for full documentation of the job logic (triggers, recipient filters, and where "Cases" are defined) to support migration of the automation into Marketing Cloud. Teams also highlighted that CARE's existing "Graduated" status is set too late to be a reliable early trigger for certificate mailings and requested identification of an earlier CARE field or reportable signal (via CARE reports/SQL) that can be used as a trusted trigger for future automated sends. Documentation and migration planning were collected to ensure future email automation ran from a documented, auditable platform with explicit recipient filtering.

Career‑path and semester edit failures were resolved through a combination of manual remediation and vendor fixes. Where the EPOS 'Studienfortschritt' tab would not accept Werdegang edits, staff applied career‑path changes via the EPOS Bookings tab or released affected profiles in CARE so the CARE/EPOS update team could make the change. Semester addition failures were traced to incorrect immatrikulationsdatum values that preceded cohort start dates; those records were corrected by fixing the enrollment date, deleting the invalid Werdegang entries, and re‑adding the semester records, after which semester additions succeeded. Multiple defects introduced by a recent CARE update — including a missing checkbox in the cohort‑change/study‑program workflow that prevented recording an exmatriculation reason, exmatriculated bookings missing exmatriculation date/reason fields, and incorrect inheritance of immatrikulationsdatum on new bookings — were fixed by vendor patches delivered in CARE v17.21.x that restored the cohort‑change UI controls and corrected booking date handling. A Simovative Help Center defect that prevented saving comments in the Werdegang was fixed by the vendor and the fix was promoted from Stage to Live (deployment confirmed 2025-03-18). Separately, inability to create or edit Vertiefungswahl (specialization choices) was escalated to the Simovative/Fachteam; the vendor applied a fix and redeployed the service (including associated DS_Vertiefungswahl/CMaaS components), and requesters confirmed the functionality worked again in Firefox and Chrome.

Investigations identified multiple distinct root causes across EPOS, CARE, Course Management and PIM; targeted remediations restored consistent enrolment and exam‑registration behaviour and removed manual workarounds. Key actions and outcomes included:

Post‑fix verification on stage and production confirmed correct participant counts, consistent enrol buttons and exam‑registration visibility, restored enrollment blocking behaviour, and removal of the previously required manual workarounds.

A custom CARE (Simovative) report was implemented that produced one row for each pairing of an active student booking and each prior inactive booking. The report filtered active (non-deleted) bookings in categories FS, OI, MSE and MSD whose immadatum fell within the last 12 months, matched inactive (non-deleted) bookings with immadatum earlier than the active booking, allowed multiple inactive-booking rows per student, and sorted results by last name, first name and immadatum (descending). Output columns included Academy ID, last name, first name, active student booking and inactive student booking, and the report was deployed to the Simovative reporting module for end-user access. For stakeholder requests that required intake-report variants (for example a Pathway intake report mirroring the 'Studierende MS' query and a DMSD variant), the base report was copied and adapted, placed under the MS reports/intake-report folder requested by stakeholders, and its filters and data source were adjusted to cover the requested program names (CS P2U and BPW - Bridging Pathway) and data locations (DS Bad Honnef, with Berlin intake added later). Requesters typically provided 2–3 sample Excel records to define required fields; where tickets arrived without samples or folder details, support requested clarifications and closed the ticket pending those artifacts. Separate CARE report variants (for example locked-account or LIBF variants) were triaged with the Sim reporting team, who usually requested sample exports and indicated a typical delivery timeline of about four weeks.

Multiple defects in CARE that affected attempt ordering, attempt counters, visibility of attempt details and Moodle e‑assessment mapping were identified and addressed. A bugfix in CARE v17.21.14 corrected chronological ordering and the attempt‑counter calculation; a migration/normalization script was executed on Stage and Live to repair inconsistent position values in the noten (grades) table that had been left unset or duplicated. Code changes and API updates were deployed so position values could be set and exposed correctly (SOAP/REST), and the normalization script assigned sane position values across related rows. A separate defect that caused the exam overview to list attempts while hiding individual attempt details and grade‑editing controls was fixed on Stage and deployed to Live; earlier Live updates to v17.14.12 had already restored missing course‑level result entry behavior. The combined fixes restored consistent chronological ordering, corrected attempt counters (including cases involving attestations or external transfers such as Turnitin), made individual attempt details and grade‑editing controls visible again, and corrected mapping of attempt data to Moodle E‑Assessment. An intermittent symptom where opening a specific grade entry temporarily reset an incorrect counter was traced to and resolved by the same ordering/position normalization work. Separately, a newly reported UI issue where students with valid in‑person exam bookings were shown as registered for online exams (actions like “go to online exam” / “cancel online exam”) and where successful Turnitin uploads displayed the wrong icon (gray “M” instead of purple “E”) in Online Studies formats was escalated to Simovative for code‑level investigation and remediation. A related, newly observed defect caused bulk exmatriculation attempts (status changes) to fail with an object(Simovative\AC5\ExamManagement\Grade\Exception\GradeNotFoundException); stack traces showed failures in GradeReadService and subsequent GradeAttemptCountService / GradeUpdateService / GradeDeleteService calls. That exmatriculation failure was logged and escalated to Simovative for further investigation and remediation alongside the other code‑level issues.

Support provided a standard checklist of required information to create CARE tickets. For employees the checklist included AC‑5 ID, full name, email, location, a full‑screen screenshot, a detailed description of the issue with concrete examples (including affected student/record details where applicable), and 1–3 contact persons for follow‑up. For students the checklist included AC‑5 ID, location, program, cohort, full name, email and matriculation number. Support explained how to find the AC‑5 ID in CARE (click the user name in the top right → 'My Profile' → 'Data' tab). Separately, the IT Service Portal (Atlassian Jira Service Desk) entries for CARE service categories were missing explanatory descriptions; support entered German texts for the portal items 'CARE Antragsverwaltung', 'CARE Community/Internetauftritt' and 'CARE/EPOS neue Anforderung', added the requested English translations (provided in ticket comments), confirmed the entries were present in the portal, and marked the content‑update request as Done. One earlier requester later confirmed their interaction was a test and that ticket was closed as 'Won't Do'.

Two related issues around CARE profile locking/unlocking were addressed and documented. The defect that caused a misleading database-access error during 'Sperrung aufheben' (while the unlock actually completed) was fixed in CARE release v17.21.3; the fix was validated on Stage (tested by Ozzi Tas) and deployed to Production, after which the database-access error no longer appeared and automation consumers no longer created duplicate manual steps. Separately, it was observed that the direct person search view did not expose lock/unlock controls (no error was shown); users performed lock/unlock actions by using the person search with the 'Studenten' (Students) subcategory instead, and this behavior was verified by the user. The section documents both the code fix for the DB-access error and the identified UI search-path behavior.

Investigations found multiple metadata, mapping and synchronization defects across CARE/VLR (Vorlesungsreihe/Terminserie), PIM/MSD, EPOS, myCampus, OnCampus and Salesforce. Combined remediation restored expected enrolments, timetable visibility, grade and exam‑admission lists and downstream synchronisation. Key outcomes and actions were: - Orphaned CARE module records left after EPOS‑driven de‑recognitions were removed by deploying an updated CARE version; inflated ECTS totals were cleared. - CARE program‑level metadata (incorrect academic‑degree values), missing Studiengang, cohort/intake and ownership records were corrected; VLR then recognised planning groups/cohorts and enrolled participants into Vorlesungsreihen, restoring lecture visibility in student timetables and structured grade/exam‑admission lists. - Cohort period/granularity and planning‑group visibility were corrected so planning groups appeared at the intended calendar granularity and immatrikulation/enrolment options were re‑enabled. - CARE course status and planning‑group membership were adjusted (courses set to “Lehrauftrag erteilt” where required and students assigned to planning groups); courses marked as started reappeared on students’ MyCampus home pages and restored course access. - PIM/curriculum omissions were fixed when CARE courses were absent from PIM study‑plan data: curricula were updated and synchronised to EPOS, after which EPOS displayed the course and allowed credit/registration operations. EPOS‑side mapping errors (courses assigned to wrong modules in EPOS) were corrected, removing incorrect module assignments visible to students. - CARE product‑offer/module metadata deficits — missing module records, absent course‑variant entries or incorrect ECTS/variant data — were completed or corrected; Curriculum Management confirmed and corrected CARE course ECTS where required so downstream recognition workflows worked. - Module‑level curricular‑ID removals were investigated and remediated: missing curricular IDs were restored at module level, the issue was traced to curriculum/version bot updates that re‑applied course versions, and Curriculum Management coordinated changes to versioning and bot behaviour to prevent recurrence. - Transfer2Epos / Salesforce integration gaps were closed by creating missing Salesforce bookings or re‑triggering Transfer2Epos events; creating missing Salesforce bookings produced the CARE booking and care‑link where downstream records had been absent. - Residual manual or individual bookings left after planning‑group reassignments were removed or corrected so only the intended planning‑group booking remained; this eliminated duplicate appointment series and listing mismatches and restored complete student‑facing enrolment pages and exam‑enrolment iframes. - Exam‑period defaults were investigated and adjusted where many lecture series had the default “no credits, no exam”; the behaviour was raised with the vendor and bulk or per‑item edits were applied where required. - A CARE/VLR bug where configured lecturers (Dozierende/Dozent:in) were not populated into created Terminserie appointment entries was fixed by Simovative and deployed to Stage and production. - A functional gap was identified in CARE’s merge‑lecture‑series feature: merging did not copy planning groups from an integrated lecture series into already‑existing appointments of the remaining lecture series; the vendor confirmed the behaviour and tracked it as a feature request. - For OWB (Online‑Weiterbildungsangebot) offers, the team confirmed and documented the extracurricular nature, the technical 10‑ECTS per‑student cap and duplicate‑booking risks; a distinct distance‑learning planning group/cohort was identified as the appropriate locus for enabling self‑enrolment while preventing duplicate bookings. - To address evaluation/export issues, a requirements workshop with the vendor and product owners was held and stakeholders agreed to use the KW Vorlesung (lecture‑series) ID as the unique identifier for course→participant mapping and as the integration key for evasys exports, removing the need for manual evaluation imports. - Temporary recovery actions used during remediation included manual enrolment into Vorlesungsreihen to restore participant visibility, re‑saving/renaming/re‑adding planning groups to force recognition, and re‑triggering transfers or synchronisations when downstream systems lacked updated curriculum/offers. - Outstanding integration gap: registered on‑campus exam appointments booked in CARE did not automatically create calendar entries in the Care Community or synchronise into the mycampus timetable; this behaviour and required calendar fields (course name/short code, location/room, timeslot) were documented as a vendor feature request and no development was implemented. These combined actions restored expected enrolments, timetable entries, grade and exam‑admission visibility, course access in MyCampus, reliable evaluation cohort mappings and cross‑system synchronisation.

Multiple interacting front‑end, client cache/profile, overlay/CSS, backend and connectivity defects produced the intermittent blank/partial appointment/term‑series panes, missing menus/lists, blocked click targets, scroll regressions, slow rendering and HTTP error pages. Resolutions and observed outcomes included: vendor front‑end fixes that removed defects causing blank or partial appointment/term‑series panes and planning‑group omissions; responsive‑layout and CSS/DOM changes that prevented controls from being pushed out of view and removed custom banners/buttons that overlapped pagination/navigation targets; a collapsed‑tree preload URL and a temporary planning‑groups dropdown to mitigate navigation gaps while fixes were deployed; and targeted performance tuning that reduced rendering overhead on very‑large datasets (notably Curricula → GPA/Statistics). A backend Curricula tree repair addressed a persistent expansion stall that could block navigation or prevent login.

Many UI failures were restored after clearing browser cache/cookies or performing a hard refresh (Ctrl+F5); where client‑side cache clearing did not help, CARE system‑cache maintenance and explicit server‑side cache clears performed by vendor/support restored functionality. A Simovative internal application cache clear resolved repeated “action failed” errors in one recurring failure class. Firefox‑specific rendering and missing ribbons were resolved by clearing cached web content and, in persistent cases, replacing corrupted Firefox profile files (%APPDATA%\Mozilla\Firefox\Profiles\) which restored menus. Alternative browsers were used as temporary work‑around while fixes were deployed, and specialist support restored portal↔CARE connectivity where explicit connection errors occurred.

View‑specific investigations produced targeted outcomes: a syntax/programming error that produced malformed VC room entries (strings like "/div.") was corrected; a lecture/tab display bug (courses omitted unless filtered by Semester+Year) was reported and placed in the vendor backlog; an instructor appointment time truncation was traced to a CampusWEB timetable end‑time configuration mismatch and documented; and iframe framing/scroll behavior was escalated to integrator teams when embedded content loaded anchored out of view. In one reproduced scenario where switching locations caused very long loads and browser crashes, selecting Curricula under “all locations” mitigated impact until vendor follow‑up; duplicate‑account/profile ambiguity was noted as a possible contributor. A targeted vendor fix addressed a bulk "status change" error that previously produced an error during appointment publishing and caused the appointment‑series view to display no appointments.

Additional observations from recent tickets: a browser‑independent, team‑wide incident produced empty recurring‑appointment edit windows that resolved spontaneously after approximately three days; support requested verification that affected courses were in status "prognostiziert" during reproduction attempts (no confirmed causal link). A macOS + Mozilla Firefox case was observed where the navigation bar could not be scrolled to the top, cutting off person search and student‑mail controls; Chrome rendered the UI correctly in that case but student notification delivery did not work via Chrome. Troubleshooting was performed for these cases but no documented final remediation was recorded in the ticket notes.

Combined vendor front‑end updates, responsive/CSS/DOM fixes, backend repairs and performance tuning, client and server cache clears, Firefox profile remediation, the VC room syntax fix, and the targeted bulk‑publish fix collectively restored appointment/term‑series rendering, planning‑group visibility, pagination/navigation clickability, and reduced occurrence of “action failed”/HTTP error pages across live and stage instances.

Support reproduced multiple grade-visibility and data-integrity failures across CARE Anzeige/Notenblatt and applied targeted remediations according to root cause. Where change-history showed score entries in an unpublished state, affected score entries were re-published on the Notenblatt, which restored grade visibility for students and the Transcript of Records. Where the structured Notenblatt view showed “CE” or omitted grades while staff could open released records, records were re-opened and re-saved in CARE without changing grade values; this re-save restored display in affected bookings (the same re-save behavior resolved incidents where grades only appeared after re-saving). Re-saves were sometimes recorded as spurious adjustment entries in change-history. Incorrect fachsemester or other transfer metadata introduced by notenblatt_copy or via the Anerkennungsbutton/FS Klausur were resolved in individual records by re-saving while vendor fixes were pursued. A functional defect in the Notenansicht/grade view was fixed in Stage and deployed to Live (validated 2025-03-18), removing a code-level cause of missing exam entries. Simovative identified and fixed underlying bugs that caused participants to be removed from grade entries and that produced errors when accessing change-history/logs; those fixes shipped in CARE releases v17.15, v17.13.15 and v17.14.7 and were scheduled for Stage/Live deployment. Simovative also implemented a code fix to preserve and display zero-point (0) numeric values when saving exam results in Prüfungsmanagement → Prüfungsergebnisse; that fix was deployed to CARE Stage and regression-tested. Visibility and change-history access were re-verified after each remediation. Separately, a Notenblatt date-display mismatch was reported where the mark publication date was shown instead of the submission/assessment date for Bongo and Turnitin submissions; this issue was forwarded to the specialist/subject team for investigation, a privacy/data-protection concern was flagged, and the specialist team accepted handover to contact the reporter for follow-up (no technical fix was recorded in the ticket timeline).

Multiple related backend and configuration issues were identified and remediated to address intermittent hangs, timeouts and export failures caused by very large result sets and excessive client payloads. Key fixes and outcomes: - Reduced payload sizes, added server-side pagination, and applied filtered participant/Termin queries; these changes were delivered in bettercare releases (notably v17.14.9 and v17.14.12) and removed the intermittent hangs across Firefox, Chrome and Edge. - Kursmanagement → Termin liste failures caused by very large room selections (example: selecting ~58 rooms) were addressed by reducing request payloads and adding server-side pagination, eliminating the hard ~50-row pagination symptom and page-freezing during navigation. - Export failures returning 400 Bad Request were resolved by increasing the web server's allowed URL/query-string length and redeploying the server, preventing oversized GET URLs when many room filters were encoded. - Create/edit failures that were caused by insufficient storage on the Simovative instance were mitigated short-term by manually increasing storage for affected windows; a permanent fix was implemented in release 17.11 and scheduled for Live. - Isolated outages where Course Management pages returned errors on every tab were resolved when the specialist team restored the Course Management pages and users regained access. - Some intermittent 'Alle Standorte' (All locations) hangs were observed to self-resolve; reproduced across browsers and devices but did not produce distinct server errors in those incidents. Remaining/ongoing items and operational notes: - A usability/performance symptom was reported in the appointment-series workflow: the 'Speichern und Bearbeiten' ('Save and Edit') button experienced long load times that caused users to click repeatedly and create duplicate appointment series. No technical fix had been applied at the time of reporting; the vendor requested full-screen video recordings of the issue when it occurs to assist analysis and reproduce the problem. - Interim user mitigations used before fixes were: selecting a specific location context to avoid full-location list fetches, exporting without room filters (exporting “All”) to avoid long GET URLs, and avoiding large multi-room selections during peak hours; these reduced frequency/severity but did not eliminate slow-loading under peak load. The above remediation steps collectively resolved the major hang, pagination and export symptoms for the environments in scope.

The requested content updates were applied to the relevant CARE pages and deployed where appropriate. For the CARE FS exam registration mask, the provided dual-study informational text was inserted on the staging environment for review; during implementation it was documented that the registration-mask renderer did not support the requested custom border or alternative text color, so emphasis was limited to the platform's existing formatting capabilities and the change remained on staging pending review before any production rollout. For the CARE BS course booking page (kursbuchung.php) the highlighted/outdated wording was replaced with the supplied new text clarifying that, from Summer semester 2025, no (virtual) presence courses will be offered and that courses can still be booked and completed online; that change was deployed to the site (https://care-bs.iubh.de/studium/kursbuchung.php). Both issues were handled as content/visibility updates rather than software defects.

The sender address produkt@iu-akademie.de was added to the CARE mailing sender-address dropdown. The change was performed by Pritzl, Christian on 2025-12-12 08:17 and the requester (Tumbrägel, Tessa) confirmed completion on 2025-12-12 17:26.

A data-driven nightly ETL and a small backend automation service replaced the manual campaign for DS thesis registrations and mitigated attempts to push data into CARE directly from ad-hoc sources. The ETL_DS_Eligibility job joined CARE, EPOS and Simovative in the data warehouse and populated a ds_app_eligibility table with computed eligibility flags (modules 1–6 passed, practical report passed, 120 ECTS / quarter logic, application PDF completeness, semester check). A Power BI “DS Registration Dashboard” used DirectQuery to that table to surface only relevant students, show exception reasons and provide review screens for staff; staff reviewed flagged exceptions while fully automated approvals applied where all checks passed. Where CARE provided no native bulk status APIs, the team implemented a small backend service that exposed a CARE REST endpoint (/api/apps/{id}/status) to apply bulk status changes (Auto‑approved, Back to student) while preserving manual‑override metadata; the same service produced certificate CSV exports and sent templated status emails via the institution mailer (noreply‑ds@...) using CARE mail templates. The team evaluated lightweight bots for one‑off bulk updates in some ad‑hoc cases. For recurring grade/result imports from SharePoint/Excel the team prototyped PowerAutomate flows that matched records by matriculation number or IU email, but found the CARE API too limited and PowerAutomate flows too error‑prone for a production rollout; no production automation from SharePoint/Excel to CARE was implemented, and existing integrations (for example PebblePad for some programmes) were used where available. The combined approach processed the peak campaign (>5,500 applications), automated routine approvals, preserved audit metadata, reduced manual effort to reviewing exceptions and avoided risky direct writes into CARE from unreliable flow tooling.

Access to profile logs was restored by assigning the required profile-level permission and, where appropriate, mirroring the permission set of a working account. Specifically, the DS_Sonderrecht permission was identified as including the ability to view the Log tab and was applied to affected accounts. In cases involving CARE Admin accounts, changes required approval and intervention by the technical/specialist team before the log UI became visible. Some incidents involved users authenticating with an alternate (e.g., student) profile or encountering the application error 'Anmeldedaten nicht korrekt'; a password-reset and technical-team processing were performed (the reset was initially ineffective in one case) and, after confirming the correct account and completing the permission changes, the Log tab and log-file access became visible and usable.

Investigations found three distinct causes for cohorts not appearing in CARE and the corresponding outcomes. First, in cases where no cohort had been created for the affected campus/study program, central administration created the missing cohort(s); once created the cohort appeared in the selection list and students could be assigned. Second, some programs used only general/program-level cohorts rather than specialization-specific cohorts; in those cases the absence of specialization cohorts was confirmed and requesters were informed that only program-level cohorts existed. Third, newly created planning groups sometimes did not appear immediately in the CARE UI due to automatic synchronization; after an automatic update (observed propagation time approximately two hours) or after refreshing the overview the missing group became visible. Each case was resolved according to which cause applied (creation by central administration, clarification about program-level cohorts, or waiting for the automatic update).

Investigations found multiple distinct root causes; each incident was triaged and remediated according to its cause rather than by applying a single universal fix. Client-side/browser state: several intermittent CARE UI failures and persistent login/session problems were resolved after clients were standardized to the latest Chrome from Software Center, browser cache/history/cookies were cleared and the browser was restarted. Transient session/login failures that returned jsonResponse: {"success":false} were sometimes resolved by reattempting login. Backend/integration state: some profiles that existed but showed empty booking details were fixed by restarting transfer jobs and escalating to development, which corrected backend records so bookings became visible. Asynchronous processing: EPOS-created bookings (including for new accounts and Fast Track transfers) were created asynchronously and became visible once EPOS finished processing. Transfer2Epos / Imma-Check: intermittent document-transfer failures for files uploaded via Imma-Check were investigated; Transfer2Epos errors were identified as transient or were fixed and subsequently transfers resumed reliably (uploads made directly to the Opportunity had been transferring successfully, which helped isolate the Imma-Check path). Duplicate-prevention logic: re-attempted transfers for edited opportunities were sometimes blocked by duplicate-creation prevention; where appropriate missing bookings were created manually in CARE after confirming canonical records. Opportunity selection and messaging: one transfer failure returned a misleading "data was already transferred to EPOS" message even though no CARE profile existed; investigation showed the user had selected the wrong Salesforce opportunity (it was not a Definite and/or not marked primary). That case was resolved by selecting the correct primary/Definite opportunity or reconciling records, and it highlighted misleading transfer error messaging when transfers were attempted against non-primary opportunities. Account linkage: at least one incident was traced to a missing Salesforce–Care account linkage (student MNR not associated with Salesforce user), which prevented initiation of certain processes; these cases required administrative account assignment or reconciliation. Mail queue blocking and background jobs: Care Antragsverwaltung submissions that did not create Salesforce cases were caused by a slow/blocked outbound mail queue; a Simovative bugfix cleared the backlog and restored case creation. Transient consumer-facing errors: a myCampus report of "Allgemeiner Fehler bei der Verbindung zu CARE" (General error connecting to CARE) was logged and later the service became available; the ticket was closed after the user confirmed recovery with no backend changes recorded. Downstream synchronization and propagation: stale timetable entries and lingering public content were traced to background synchronization and propagation delays; administrative deletion and backlog clearance by specialist teams were required before downstream systems reflected changes. Each incident was resolved by the corrective action appropriate to its root cause (browser state refresh, transfer/job restart, development fixes, manual record creation or administrative account assignment, mail-queue bugfix, or waiting for asynchronous jobs to complete).

Incidents were resolved by addressing multiple upstream-data, mapping, environment, and application-level causes and by coordinating across curriculum, automation, scheduling and integration owners. Key actions that resolved occurrences were summarized as follows:

Reported impacts ranged from a few dozen profiles to roughly 3,000 affected students at a site. Restorations required knowledge of Minerva/onCampus processing flows and coordination between curriculum management, automation owners, Simovative/scheduling and integration owners.

Space permissions were reviewed and updated to include the affected user. In addition, an extra space administrator was added to the Care Confluence space. After the permission adjustments the user was able to access the space.

An administrator verified that the option had been disabled or removed by a product update; the control no longer existed in that editor view. The only remaining location for the paste-formatted-text option was the text template editing mask. Users were informed that the feature was no longer available in the email editor.

Duplicate or multiple booking/contract entries in the candidate's CARE profile were removed or consolidated so that only a single unique booking ID remained for the affected semesters. In one case two booking IDs (10930071 and 11176626) were present on the same career entry and the career/booking records were adjusted to leave a single booking reference. After the updates the profile showed a single contract/booking record and enrolment/certificate generation and printing succeeded.

Multiple CARE<>LDAP outages were investigated and resolved by addressing two distinct root causes. In certificate/availability incidents, the CARE side was returning 504 Gateway Time-out responses or presented an updated certificate set from the upstream provider; the provider implemented the required certificate replacement/adjustment and service fixes, after which CARE<>LDAP synchronization resumed and AC5‑Sync ran again. In a separate replication outage the CARE replication container was not running and the SSH tunnel to Dogada was failing because an infrastructure orchestration logic error contained a condition that caused the container to be killed; DevOps deployed a code/config change removing the erroneous condition (an initial deploy required follow-up adjustments) and restored the replication container and tunnel. Following both types of fixes, a full synchronization ran to catch up on accumulated changes; Moodle's local_iubh_auth.userinfo cache and user profile fields were subsequently refreshed. Relevant indicators included /moodledata/ac5_sync_jsonresponse.log entries (for example "-- ERROR #1660717211 --"), 504 Gateway Time-out responses, absence of a replication connection, and user reports of "Benutzername nicht gefunden."

The deletion could not be recovered from Stage because the contact-history entry was not present there; no automated restore from Stage was possible. The ticket recorded that the attachment was permanently removed from the production contact history and no in-system copy was available to restore. (No alternate recovery from backups or a staged copy was documented in the ticket.)

Support identified that two different root causes appeared in these incidents. In cases where the ODBC client drivers were missing, the problem was resolved by providing and installing the correct drivers: the Amazon Redshift ODBC driver (per AWS documentation) for DataWarehouse access and a MySQL ODBC driver for the CARE replica. Drivers were distributed via SCCM/Software Center or installed during remote-support sessions (TeamViewer/Teams) as needed, and users were assisted with DSN creation. Separately, a ReTool invoice application on CPGAZU1ReTool1 experienced ODBC failures only when the encrypted/SSL connection option was enabled; disabling encryption allowed the connection but was insecure. For that ReTool case no technical fix was applied and IT Ops recorded a decision not to implement a change.

Access was restored by reestablishing parity between the affected account and a verified reference account and by addressing recent CARE UI/workflow changes. Typical remediations that resolved incidents included re-granting, revoking or synchronizing permission groups (examples: DS_Kursmanagement, DS_Pruefungsamt), restoring missing flags in the CARE role string (for example adding a missing 'C' community flag), and aligning connected-platform rights (myCampus/community) and core location settings (which influenced visibility of items such as Rooms/Buildings). When UI elements were not visible or pages stalled, support impersonated the account, refreshed or reset the user profile/menu and had the user reauthenticate via Okta; visibility often appeared after a short propagation delay (~5–10 minutes). Clearing browser cache/cookies or testing in an incognito window or different browser (Firefox/Edge/Chrome) was used to confirm changes and to resolve browser-specific intermittent cases. When assigned rights already matched a working account, support supplied updated UI guidance for the post‑restructure CARE interface; when UI elements remained missing despite correct permissions, specialists investigated and fixed product defects (for example a CARE Stage bug that removed the exam-results tab). For incidents affecting multiple colleagues, support requested a verified reference user and coordinated a collective remediation/campaign; some tickets were closed after administrative handover (for example approver corrections).

Product confirmed the release was a visual/UX update only and that no functional changes to existing Better Care workflows were introduced. An announcement and a walkthrough video were posted to the Care Allgemein channel. It was confirmed that users cannot fully disable Better Care via the UI (there is no reset/disable button); hiding the "Better Care Aktiv" badge only affected appearance and did not change behaviour. A short-term workaround that reverted the visible tint was to clear the affected site’s browser data (Cookies and Local Storage). The product team also communicated a planned backend change to remove the new colouring/behaviour in approximately 2–3 weeks. No user action was required for workflow functionality at the time of the release.

Investigation found two related causes. First, background grade-sheet recalculation/update jobs wrote audit log entries even when the final grade value did not change; those technical entries were visible in the history and caused misleading attributions. Second, a UI/display change removed the previous history filtering/grouping behaviour and relocated edit controls (date-click → gear icon), which increased visible log volume, removed the previous per-attempt association in the history UI, introduced slower load times (2–10s reported), broke Recognition Bots that relied on the old control, and removed the deletion confirmation flow in the UI. The previous history view that suppressed or grouped technical entries could not be restored without redevelopment. The problems were recorded as tracked feature requests/regressions: suppress or filter technical recalculation audit events (or avoid writing audit entries when no effective change occurred); restore or reintroduce per-attempt association/grouping in the history view; address the performance regression in history loading; restore a confirmation step for grade deletion; and restore or provide a bot-compatible edit interface or API. No immediate code rollback was performed; the behaviour was kept as a known limitation and tracked for future development.

The missing communities were provisioned in both Stage and Live on 2024-11-22, making the environments available for content population and testing. For the HU FS site, the required community configuration was copied from an existing HU community to populate the new instance. The rollout delay was traced to waiting on third-party certificates and infrastructure migration steps; once those prerequisites were resolved the communities were created and made accessible.

An investigation confirmed that deleting inactive rooms was disallowed by underlying protocol/thematic constraints and that adding a UI option to hide inactive rooms would require product development. The vendor (Simovative) declined to implement a hide-inactive-rooms feature; that capability was deferred to the planned CARE replacement (EPOS). Separately, a display bug in the Kursmanagement/Stundenplan view—where site addresses and room labels were not shown correctly and inactive/virtual rooms were listed improperly—was escalated to Simovative; they deployed a fix to production and users verified that schedule and room displays were corrected. In the interim, inactive rooms remained visible and were being marked by renaming (for example with an 'INAKTIV' prefix).

Investigators confirmed there were no true duplicate bookings: records referred to distinct physical rooms that either shared the same numeric identifier across buildings or had incorrect names/labels due to a bad data import. The timetabling view in MyCampus was changed so building identifiers were shown alongside room numbers. Incorrect room entries and imported labels in CARE were corrected after coordinating with the central course management team and the Fachteam (specialist team). Support cases were routed to the responsible teams when ownership of the room data was unclear, and course administrators and affected instructors were informed of the corrected assignments. After these changes the timetable display, booking records and on-site information were aligned and the apparent double-bookings and availability errors did not reoccur.

The ticket recorded that investigation confirmed an automatic status change recorded in system logs on the enrollment date. No corrective action, configuration change, or permanent fix was documented in the ticket record.

The incidents were resolved in two areas. For DokGen-related issues, a blacklist rule was implemented to block printing of the Certificate of Study when a student’s status equaled 'unter Vorbehalt', DokGen templates/settings were updated to prevent generation of Immatrikulation/Exmatrikulation certificates for program records with no active student status (notably Early Admission Master Program records), and the legacy/incorrect error message was replaced with the requester-supplied explanatory text; the template changes and blacklist rule were deployed and verified. For the FS certificate module, the query that enforces the three-month restriction for Immatriculation certificates was re-run to restore the time-limited download control; the query execution was confirmed and the restriction was observed to be in effect (example affected IDs included MNR 9190663 and IU14107678).

Support reproduced the loading/hang and escalated the issue to the Simovative vendor. Simovative implemented a fix; the vendor-marked resolution closed the incident on 2024-08-09. Earlier local troubleshooting (session refresh and cache/logout) had been suggested but the persistent infinite-loading condition was resolved by the vendor-side correction.

The incident was escalated to the Simovative vendor. Simovative found a bug in their mail-sending/queueing component that caused outgoing CARE messages—including automated application and notification emails such as exam registration confirmations—to become stuck in the vendor queue (visible as "Versand wird vorbereitet") or to be delayed/dropped without producing local error codes. While the vendor investigated, staff were advised to check the application for missed notifications as a temporary workaround. Simovative deployed a fix that cleared the stuck queue and restored normal mail delivery; in some cases queued messages were delivered after several days even without local intervention. Message flow returned to expected behaviour and the incident was closed.

Incidents were handled by escalating affected cases to the specialist document-generation team. In incidents where fixes were applied, specialists intervened in the Care/MSD/FS document-generator pipeline and corrected the certificate/enrollment-letter rendering logic; after those interventions documents rendered correctly and became printable or downloadable again. Most tickets did not record specific error codes or detailed remediation logs, and post-fix validation confirmed restoration of rendering and printing functionality. Some cases were forwarded to specialists without a technical remediation recorded in the ticket lifecycle; those tickets remained unresolved in the support system and were sometimes auto-closed by automation without a recorded technical fix.

A new English document template was created and uploaded. Template content and data mappings were corrected so footnotes/contact details and the logo used English variants, signature placement and source were corrected, GPA formatting was adjusted to the requested one-decimal format, duplicate academic-degree printing was suppressed, and the specified static name was set to appear as required. The work was implemented in the CARE document generator (vendor-assisted) and verified in testing.

Support removed the outdated news post on behalf of the user (admin deletion) to address the immediate nuisance. The PHP "allowed memory size exhausted" error was noted in the ticket but no change to backend PHP memory limits or application configuration was recorded as part of this ticket.

The issue was escalated to the vendor (Simovative). A vendor-side fix was applied (documented in Simovative Help Center), and customers used a manual workaround of editing the appointment series to add planning groups until the vendor patch was applied. After the vendor fix, planning groups were correctly carried into appointment series.

Support deployed a fix to the live CARE system to restore the room-name display. Users confirmed that room names reappeared after the fix and the ticket was closed.

Incidents were escalated to the CARE specialist team (fachabteilung). The specialists identified and fixed an underlying backend issue affecting department-specific CARE portals; the specific technical changes were not recorded in the tickets. One incident included diagnostics (Log-Id: 66bdad93c1e6f6.59828985, Errorcode: 2). After the specialist fix, the affected portals (CS and SBM) accepted browser logins and students were able to access the portals and submit exam-incapacity requests; reporters verified restoration and the tickets were closed.

A developer (Keller, Tobias) implemented a code change that suppressed the unexpected EPOS popup for non-interactive/service bot accounts in Better CARE. After that change, automated bots ceased being interrupted and the random dialog no longer appeared during bot-driven workflows. Separately, a ticket recorded the popup appearing specifically when an RPA bot opened the "finance" tab and then attempted to switch tabs for particular student records; that instance was documented as blocking (the bot could not close the popup) but contained no recorded technical resolution and was escalated to a specialist team without follow-up in the ticket.

Support staff verified the users' Okta accounts and linked app configuration and found no issues on the identity side. Users were referred to the separate PMS administration/service team via the PMS service portal. The PMS service was restored by the PMS team the following day and normal access resumed.

The ticket was escalated to the specialist Student Communication Team for process guidance. Support staff informed the user that bulk/group emails were no longer to be sent from CARE and directed them to the Student Communication Team for the appropriate channel and policy. No technical changes or fixes to CARE were applied as part of this ticket; the inquiry was closed after being forwarded and subsequently auto‑closed by Automation for Jira due to inactivity.