Incidents were resolved by restoring correct site owners and role assignments, repairing Entra/Azure AD and Microsoft 365 group membership, and correcting migration path/name mappings so permissions propagated and owners could reapply grants. Where site owners were missing or unknown, recovery included re-establishing explicit site owners or temporarily elevating tenant-admin privileges so site-level grants and SharePoint-group reassignments could be made. Library and file access was recovered by repairing SharePoint-group membership and direct role assignments, reissuing or replacing expired sharing links, and by confirming or resetting sharing-link expiration and access scopes; SharePoint/OneDrive sharing activity and audit logs plus Exchange message-trace checks were used to verify share/upload timestamps and mail delivery when users reported delayed or missing notifications. Access-request noise was addressed by reviewing site access-request routing and recipient settings and by removing unintended approvers or adjusting group membership so only appropriate owners or delegates received requests. Service-principal and connector failures were attributed to missing application-level Graph permissions, absent admin consent, or lack of explicit site-scoped grants; remedies included applying correct application permissions (e.g., Files.Read.All, Sites.Read.All), granting Sites.Selected with explicit site assignments and tenant admin consent, or provisioning an organizational-managed service account where delegated sign-in was not supported. Third-party add-in and deployment problems were resolved by provisioning the tenant or site app-catalog in the correct scope and involving Global Admin where required; some deployments to very large site collections succeeded only when deployed from the proper app-catalog context. Upload and Explorer/Teams UI failures sometimes correlated with network filtering or inspection—these were isolated by testing on alternate networks and escalated to network teams when persistent. SitePages/navigation issues were repaired by locating moved pages, republishing drafts, removing pinned links to unpublished content, clearing held checkouts and orphaned embedded authors, and republishing. Teams/channel-folder incidents were fixed by confirming Microsoft 365 Group/Team status, reassigning group owners/members and re-binding or removing broken channel-folder mappings; folders created by departed users were deleted or reassigned when necessary. Scale and storage constraints were addressed by planning library splits or migrations for very large libraries, relocating or renaming items when path-length or file-size limits prevented sync/migration, and by shortening paths to resolve OneDrive/File Explorer sync failures. OneDrive sync problems were also corrected by removing legacy/premigration sign-ins, relinking or reinstalling clients. Automation flows that suppressed items or applied unintended permission changes were reversed and affected libraries were reindexed so search returned expected results. Media playback issues were resolved by aligning storage and permission models or migrating media to supported services. Combined application of owner/role restoration, group membership repair, reissuing/adjusting sharing links and verifying delivery via audit/mail traces, reassigning or provisioning proper app/site registrations with correct Graph/Sites.Selected permissions and admin consent, republishing/relinking pages/navigation, clearing checkouts and embedded authors, deploying app/site-catalog add-ins in correct scope, reversing harmful automation and reindexing, migration path/name remediation and correcting OneDrive client state resolved the reported Access Denied/403/404, missing UI/search/list items, sync, channel-folder and app authorization incidents in the reviewed cases.

Missing or partially migrated SharePoint lists, Site Pages, OneDrive content, and broken integrations were resolved using backups, migration-export replays, vendor-assisted migrations, and targeted configuration fixes. Site Pages left on source sites were copied or restored from migration exports and unrecoverable Home.aspx pages were rebuilt in the target site. AvePoint restores and vendor replayed migrations corrected incomplete OneDrive and list transfers; Dropbox→OneDrive rename/duplication problems were resolved by re-running transfers from exports and removing duplicate copies to re-establish canonical files. Items that had been skipped because they referenced missing, external, or student accounts were reconciled either by mapping or recreating the referenced accounts/records or — when the authoritative data resided in an upstream system — by engaging the data owner (for example, the Academia team) to populate the missing student records so SharePoint lists returned expected content. An automation flow that had been paginating only the first 100 items was fixed; after it processed the full dataset, Teams membership and list records reconciled. Third‑party integrations and app references (Jira, desktop apps, approval flows) were validated and either reconnected or files were restored/recreated in expected paths. Microsoft 365 Group mailbox anomalies were traced to mailbox type and visibility settings and handled by adjusting mailbox type/permissions or converting to a shared mailbox where appropriate. Users who could access SharePoint in a browser but not via Finder/OneDrive sync had their OneDrive clients relinked and library permissions reviewed so the client could sync; client sync logs and tenant-linkage were audited where operations showed no explicit error codes. OneNote notebook ownership and locations were audited and notebooks were relocated or reassigned into the appropriate SharePoint site or user OneDrive with permissions updated. Cross-tenant file-move attempts initiated from File Explorer/desktop sync that appeared to complete locally but did not upload or create functional links in the destination tenant were remediated by performing tenant-aware migrations or vendor replay from exports, restoring canonical files in the target tenant, removing incomplete local artifacts, and recreating links/shortcuts that used destination-tenant paths so bookmarks and direct links worked. Stakeholder meetings were held to confirm expected link/bookmark behavior, clarify authoritative data owners, and align timing and scope before further migration work proceeded.

Requirements were assessed and SAFE was identified as unsuitable for one-way, time-limited provisioning in this use-case. OneDrive file or folder sharing was recommended for one-way, link-based delivery that supported multi-GB files and video content with temporary retention (approximately 6–12 months). A SharePoint Extranet or a dedicated SharePoint shared site was recommended when a portal-style experience or multiple internal owners were required. For collaborative editing needs, document-specific OneDrive or SharePoint links were used and external access to the site or library was granted; third-party transient transfer tools (e.g., WeTransfer) were not used when co-editing was required. Files that exhibited browser-compatibility problems (such as Excel files that only opened in the desktop app, suspected DDE) were escalated for specialist troubleshooting and were not resolved as part of the transfer action.

Two distinct root causes and resolutions were observed. In cases where the authoritative HR record was incorrect, the HR team updated the job-title record in the authoritative HR system and the change propagated through directory/profile synchronization; the updated title then appeared in SharePoint profiles after propagation (observed to take up to seven days). In cases where a specific SharePoint page or web-part continued to show a stale display name or surname despite profile updates, the site owner edited the SharePoint page, removed the user object entry from the list, and re-added the user object; this refreshed the displayed profile name and resolved the issue.

Investigations identified several recurring root causes and what resolved each. When SharePoint blocked an external domain, tenant or site-collection administrators added the domain to SharePoint’s allowed-embedding / HTML Field Security lists and embeds then rendered across browsers. Authentication/login endpoints that returned X-Frame-Options or CSP frame-ancestors or otherwise refused framed connections were resolved by coordinating with the external service to remove or relax frame-restricting headers or by altering the authentication flow when framing remained unsupported. Classic SharePoint content surfaced as a Teams Website "Website" tab in the Teams desktop client produced 401 UNAUTHORIZED for non-owners while the same content worked in the Teams web client; these were resolved by surfacing content via a native SharePoint tab or by using the Teams web client to avoid the desktop Website-tab authentication path that differed from browser behavior. Navigation breaks caused by links rewritten by Microsoft Defender for Office 365 ('.com.mcas.ms' fragments) or other link rewriting were resolved by restoring clean direct URLs, replacing rewritten links with external-link targets or shorteners, or ensuring navigation opened in a new tab. 'Access denied' or refused-connection symptoms affecting only some users traced to Azure AD/Entra group membership, course enrollment state, or SharePoint permission inheritance and were resolved by correcting group membership, SharePoint item/page permissions, or re-enrolling users where necessary. Where the Learning Hub or specific SharePoint sites were owned by another team, incidents were escalated to that owning team (for example, Learning Hub issues were routed to people-projects@iu.org) for investigation and remediation. Attempts to embed SharePoint content from external portals using non-Azure SSO (for example Okta) were observed to be blocked by SharePoint-side restrictions; documentation referenced Azure AD app-registration scopes (Site.Read.All or Site.Selected) as relevant for app-based access, and such cases required SharePoint-side configuration or app-permission changes — in at least one USU Knowledge Center ticket no technical change was implemented.

Support classified each missing artifact’s state (unpublished/draft, deleted and recoverable, moved/renamed, permission- or ownership-restricted, or part of a soft-deleted site) and applied remediation matched to that state. Unpublished or draft pages were republished by site owners when appropriate and stale News webpart or Start Page entries that referenced deleted or draft items were removed to clear broken links. Deleted pages, files, folders and shared items were recovered from the appropriate recycle bin when entries existed (site-level Site Pages recycle bin, the site Recycle Bin where the file lived, or the owner’s OneDrive Recycle Bin). Entire soft-deleted SharePoint sites were restored from the tenant Deleted Sites area in the SharePoint admin center; restoring a deleted site returned its OneDrive/Teams-synced shortcuts and folder links. Version History and site versioning were reviewed and available previous versions were restored when edits caused content to appear missing; limited or absent version history prevented recovery in several cases. Support used audit logs (including 'System' deletion entries consistent with automated Teams/Microsoft 365 group/site removals) and Correlation IDs to distinguish deletions from permission issues and to trace actions. Where ownership or permission-scope changes produced access-denied or 'item does not exist' messages, remediation involved restoring the item or correcting ownership/permission scope so links and share operations succeeded. Broken or stale share links that pointed to an incorrect my.sharepoint tenant domain were corrected, after which access to OneDrive/SharePoint-hosted Teams recordings and shortcuts was restored. Agents sometimes joined users in interactive Microsoft Teams sessions to diagnose UI problems (for example a shifted navigation bar that hid the Files/Recycle Bin entry) and then navigated to the correct Teams site/SharePoint recycle bin location to recover Teams recordings. Private-channel files were checked in their separate SharePoint site collection and its recycle bin. When items were not present in any recycle bin, support documented audit-trail and backup options; Microsoft Purview or tenant-level audit searches were noted as ways to surface evidence of permanent deletion but were sometimes out of scope for the responder and required tenant-administrator or Microsoft support involvement. Items older than container retention windows were escalated to tenant administrators or Microsoft support for possible recovery. Observed retention windows in incidents were approximately 30 days for site Recycle Bins and Deleted Sites and about 93 days for Teams/OneDrive meeting recordings.

Investigators confirmed access tokens were being issued but the HTTP Authorization header lacked the required 'Bearer ' prefix. The API calls were corrected by prepending 'Bearer ' to the access token in the Authorization header (Authorization: Bearer ), after which the SharePoint API requests succeeded.

Incidents were resolved in multiple, root‑cause–specific ways. When browser or authentication state caused missing content, repeated sign‑in prompts, or client‑side errors, restoring the user’s browser/authentication state (full reloads, new browser profile or private session, signing out and signing back in, or switching browsers) made content and permissions visible; re‑authenticating with the correct account context and re‑establishing previously declined consent exposed administrator‑permission changes and hidden content. Problems that presented as empty search/dropdown controls were sometimes traced to declined consent or application business logic rather than an infrastructure fault. OneDrive sync anomalies that blocked saving or editing from File Explorer correlated with overwritten/deleted field values and inconsistent version records; removing/unlinking the OneDrive sync link restored save/edit capability — some removals failed initially but succeeded on retry during a support session. Device‑ or browser‑specific failures (mobile/tablet incompatibility, Teams desktop app anomalies on macOS) were resolved by using a different device or desktop browser or by addressing the local device state; technician‑run updates (Dell CommandUpdate/SupportAssist and BIOS update) and reboots restored responsiveness in cases traced to the local device. Local connectivity issues (intermittent router/internet disconnects or onsite WLAN problems) caused occasional “can’t connect to server” or extreme slowness and were resolved by restoring local network stability. Client‑side JavaScript errors combined with misconfigured audience‑targeted web parts had hidden broken elements until browser/auth state was cleared; intranet search or direct library access provided alternate paths when web parts or shortcuts were not visible. Specific observed patterns added by recent tickets included Teams’ in‑app file viewer returning a stale Excel preview for read‑only users while downloads and SharePoint version history showed the current file (support could not reproduce or document a consistent fix), and intermittent, user‑scoped “Access denied” incidents that surfaced correlation‑IDs and primarily affected the Teams desktop app on macOS despite correct group membership and sign‑out attempts. For ambiguous rendering errors, support validated link correctness and owner‑granted permissions; some incidents remained unresolved pending deeper correlation‑ID tracing by product support.

Incidents were resolved by addressing site-level sharing restrictions, Azure AD guest presence and mapping, permission scoping, People Picker/name-resolution issues, and any cross-service onboarding problems (Exchange mailbox and telephony provisioning). For SharePoint sharing failures, sites that were restricted to “Only people in your organization” were changed to allow guests or partner domains were added to the site-level allowed-domain list; where partners required isolation, dedicated SharePoint sites were provisioned. People Picker/name-resolution problems were traced to missing or variant email objects, group-based account representations, or Office 365 group membership discrepancies; these were resolved by reconciling email variants and group membership, ensuring the user existed in the tenant or was invited as an Azure AD B2B guest, and reissuing guest invites when needed. Guests who needed to upload or move files were placed into groups with Contribute/Edit permissions which restored file operations. Site owners were identified via Site settings → Site permissions so outstanding access requests could be approved. Guest-access failures were restored by re-sending invitations, performing Azure AD B2B guest invites from the partner tenant, issuing guest re‑authentication links, or using an admin invite plus the user retrying the original site link; in several cases access succeeded after a re-invite or retry even when the initial invitation email was not received. Retention and audit requirements were met by applying retention policies/archival workflows and preserving exported audit logs tied to the site. When partner licensing prevented alternate delivery (for example Power BI restrictions), SharePoint file exchange was used. Tickets that involved onboarding across services required coordination with Exchange and telephony teams; one case recorded incorrect assignment of external addresses into a shared Exchange mailbox and separate Cloudya provisioning requests, which were handled alongside enabling SharePoint access. An intermittent OAuth/OWA stepupauth.aspx blank‑page redirect was observed during link-sharing in at least one case; that occurrence ceased without recorded technical changes and was closed as resolved after recurrence did not reappear.

Choice/metadata columns were added and normalized across affected lists and the data model was migrated so downstream tools could rely on structured values. For thesis submissions a required choice column for unit/type was created, existing items were backfilled, and Power Automate confirmation templates were corrected and updated to include the new unit/type metadata. The imported teaching-formats/exam-types table was converted to a dedicated SharePoint list and key attributes were represented as explicit choice/metadata columns; exam-type values were mapped to downstream exam tools and role indicators. Visitor-facing presentation was improved by creating filtered site views, adjusting Card/List layouts and column formatting so key fields were visible and filterable, and by adding help text where multiselect semantics required clarification. For the Awards list (IUG-Intranet-IUG-Comunications/Lists/Siegel) the expiry workflow and permissions were hardened: a new Date column was introduced and values were migrated (the legacy text column was retained temporarily to avoid breaking the connected PowerApp), the PowerApp was coordinated and updated to use the new Date column, and a boolean/no-expiry indicator was added to preserve entries that should not trigger reminders. Power Automate flows were built/updated to send automated email reminders 30 days before expiry while explicitly skipping items with the 'no expiry' flag or legacy '-' placeholder; mandatory receipt and expiry requirements were enforced on new submissions, with the no-expiry option supported. Per-item ownership was implemented by applying item-level edit permissions (breaking inheritance and granting the listed Owner appropriate rights via an automated flow) so the person in the Owner column could edit their row without exposing other sensitive data. Sensitive fields were protected by adjusting list access and by using flags/archival lists for records that required restricted visibility; an Active/Archive flag and an automated archival process were added for expired items. Changes to list schema, flows, views, and PowerApp connectors were deployed to production and applied to the relevant lists and flows.

The Hero web part was moved into a site section layout that the web part supports (for example a 2/3 + 1/3 column or a full-width section). After placing the Hero web part into a compatible column/section, the previously disabled options for levels and tiles became available and the web part could be configured normally. The page edit was then saved with the supported layout.

Support verified the student’s uploads using screenshots and the downloaded submission overview and discovered two submission notification emails/links. One of the emails pointed to the correct upload folder that contained all submitted files, while the other link showed an empty folder. The instructor opened the correct upload folder and located the thesis files, resolving the incident.

Site display names and site URLs were changed to the requested new names and adjusted to point to the replacement or parent site where required. When a draft homepage lived at a different URL, SitePage content was moved into the parent site, the parent site was set as the start/home site, the page was published, and visitor groups and permissions were restored. Intranet/navigation labels and navigation links were updated to match the renamed site and point to the correct URL, and navigation ownership was handed to the business unit for ongoing link updates. The technician coordinated the cutover with stakeholders (a Teams meeting) and verified the changes. Visibility anomalies were attributed to propagation and client/browser caching; clearing caches or refreshing/rebooting clients resolved delayed name or navigation label updates for affected users. It was confirmed that communication/intranet sites were separate from Microsoft Teams-connected team sites and their Files libraries, so moving or disabling an intranet page did not affect team-internal Teams folder structures. Exchange mail-distribution sender display names were updated and verified. Remaining internal elements (for example visible controller or internal list names) were identified and documented as distinct from display names; technicians checked for references (Power Automate flows, SPFx/custom code, forms/dataverse integrations and list internal names) and deferred renaming until dependencies were verified to avoid breaking links. List growth was assessed — the tenant showed performance degradation in testing as lists approached roughly 2,000 items — and redesign or migration options for large lists were discussed with stakeholders.

The offending app ('SharePoint Bot S1') was identified and removed from the Teams channel/group. The channel was monitored for recurrence and no new bot messages were observed after removal. Historical bot messages were not deleted as part of the action.

Navigation and homepage links were updated to restore discoverability and stabilize site navigation. Specific actions included renaming menu entries and repositioning them under appropriate parents; adding the Leadership Space as a direct tab/link to its SharePoint site and surfacing it alongside the IUG Leadership Team in Microsoft Teams; adding a Lecturer Info Point link to the intranet homepage after routing via the homepage contact and handing implementation to the responsible owner; creating a SharePoint site for Team Academic Administration and adding its navigation entry under Rektorat while notifying the requester about possible addition to the Intranet Hub; and converting Fleet Management’s Sonderformen Mobilität display into a stable link to the SharePoint page containing explanatory videos. For navigation instability where links disappeared or reverted unexpectedly, activity logs and edit histories were reviewed (initially not showing the editor), site and intranet permissions and visitor/editor role assignments were audited, browser-cache and publishing behaviors were checked, and navigation entries were re-added and re-published or converted to stable link items. For FAQ/page-visibility reports where pages were hidden from the default overview, the issue was escalated to the specialist SharePoint team and a Teams meeting was proposed for further analysis; no immediate technical fix was applied in the ticket. Requesters and relevant content owners/stakeholders were informed of all changes and escalations.

Search relevance and missing-result issues were mitigated by deploying Microsoft Search bookmarks (keyword promotions) to steer problematic queries to the intended site pages and external targets, and by adjusting content-level signals (titles, metadata) to improve ranking. The team documented that legacy Query Rules / query elevation were deprecated and that external BrandHub sites could not be surfaced directly in SharePoint search, so bookmarks/promotions and content changes were used as workarounds. An additional issue was observed where depublished or checked-out pages remained discoverable via the intranet search; this behavior was logged and investigated as a search/indexing visibility problem, but no final remediation was recorded in the ticket set.

Investigation confirmed the SharePoint site/group was provisioned by an M365 Group (a Teams team) and therefore could not be deleted independently. The user removed the associated Microsoft Teams team, which deleted the underlying M365 group and removed the linked SharePoint site. It was also noted and communicated that, when deletion of the entire group is not acceptable, the alternative is to clear or relocate the document library contents instead.

Expired SharePoint API credentials were renewed or replaced for each affected integration. For the EPOS DAM integration a new Azure AD SharePoint app registration and client secret were created; the new client ID/secret were recorded in the team's credential store and communicated to EPOS DAM service owners so authentication continued without interruption. JungleMail connections were changed to the "Advanced" connection type on 2026-01-12; a user confirmed successful login on 2026-01-14 and the Advanced connection setting was applied for all JungleMail users, restoring newsletter delivery access. For Salesforce (Care) the CPC team renewed/restored SharePoint API access by re-enabling the API token, after which SharePoint links in Salesforce returned content and student file access was restored. Credentials, connection contexts, and the applied changes were documented with the relevant service owners.

Detection and missing-entry incidents were resolved by moving flows away from relying solely on the trigger and instead using explicit version-change detection. Versioning was enabled on the affected SharePoint libraries and lists and flows used the 'Get changes for an item or a file (properties only)' action to compare current and previous versions and confirm whether the specific column (for example Status/choice fields, deadline/date columns, or assessment-result fields) had changed to the target value; conditional logic proceeded only when that exact column change was detected. This version-change approach was applied across choice/status, date/deadline and automated-sharing flows and restored downstream actions (publish/move, permission grants and notification emails) in subsequent runs. Separately, several incidents traced to Microsoft service outages or to high-volume processing had produced corrupted or incomplete flow/log entries; investigators repaired corrupted logs where possible and restored flow-run reliability. In cases where SharePoint-triggered sharing or recording flows did not run and no immediate technical fix was available, affected folders or list items were shared or corrected manually and some tickets remained unresolved due to insufficient run-history (older than 30 days) or inconclusive logs.

A scheduled automation process was implemented that reconciled thesis submissions with authoritative exmatriculation dates and enacted permanent deletion only when the five-year threshold had been reached. The design used a dedicated service account (secured in 1Password/SAFE) and a scheduled Power Automate flow that looked up exmatriculation dates from the student data feed (initially via Care exports, with EPOS integration planned) and matched by student ID. Before deleting, the flow recorded immutable deletion metadata (student ID, file path, original submission date, exmatriculation date, deletion timestamp, and operator service account) into a secure audit store. Files were removed from the library and then purged from the site recycle bin using SharePoint REST calls to ensure they were not recoverable; the audit records were retained separately to satisfy logging requirements. Access to the tool was limited to the dedicated service account and automated processes to reduce human error, and backups/retention policies were reviewed to avoid conflicts with permanent deletion.

The issue was resolved by opening the workbook in the Excel Desktop application instead of using Excel for the web; hyperlinks and previews behaved normally in the desktop app. The support session ended after the desktop verification and the temporary file sharing with the technician was revoked.

Multiple automated flows and integrations removed manual steps and prevented duplication, ensured consistent naming/targets, maintained per-item permissions, and synchronized membership data. For Jira-triggered project workspaces a Power Automate flow was used (triggered by the Jira webhook/connector) that treated the Jira issue key as the canonical identifier, checked SharePoint for an existing folder (or consulted a lightweight SharePoint list recording created folders) to avoid duplicate creation, created the project folder and nine standardized subfolders, and then broke inheritance and applied role assignments so project leads received Full Control and members received Contribute. Internal principals were resolved via Azure AD identifiers and external collaborators were provisioned by issuing guest invitations before permission assignment. Where the built-in connector lacked role-assignment capability, SharePoint HTTP/REST actions or Microsoft Graph calls were used. For group membership needs a scheduled Power Automate flow retrieved Microsoft Teams group member data and populated/updated a SharePoint list to provide an authoritative membership source for downstream permissions and reporting. For publication automation an interface between SiteFusion and SharePoint determined target folders by publication type and course code, detected existing files by naming conventions, created a _BackUp folder when missing and moved matched existing files into it, then uploaded the current Print PDF and E‑PDF. That integration used the SiteFusion API where available and an RPA approach (UiPath) when direct APIs were impractical. Cross-cutting practices included using canonical identifiers (issue keys, course codes) or naming-pattern detection to prevent duplicates, lightweight existence records to make flows idempotent, and scripted REST/Graph calls when connector actions were insufficient.

Incidents matched two distinct causes and were resolved differently. Client-side integration failures: Windows cases involved Acrobat/Reader interacting poorly with OneDrive long paths; resolution included replacing the Acrobat/Reader installation and relocating/shortening the user's synced folder to remove OneDrive long-path (MAX_PATH) warnings, after which Acrobat/Reader could open and merge PDFs directly from the synced location. macOS (Monterey) cases presented as Finder reporting synced SharePoint files as damaged; affected users regained access by opening the site/folder and files from the SharePoint web interface rather than via the synced Finder path. Throughout troubleshooting, browser and Teams previews remained usable alternatives for affected users. File-level corruption: some tickets described files that failed to open in both the desktop application and the web/Excel Online interface (suggesting server-side file damage); these incidents were treated as file-specific corruption rather than client integration failures. In at least one matched ticket no definitive remediation was recorded for the suspected corrupted file.

A dedicated SharePoint site with a document library was established as the agreed archive target in both mailbox/PST and third‑party document scenarios. For Exchange/mailbox migrations the support team documented multiple practical migration options that were used: mailbox exports and PST exports, PST→EML/MSG conversion approaches for item‑level upload, and automated transfer patterns using Power Automate or group mailbox export where appropriate to the required retention and access model. For the d.velop SaaS case the team recorded that the Power Automate d.velop connector did not provide a download action; they investigated the d.velop DMS API and supplier export capabilities and documented an API‑driven approach. The documented d.velop approach included extracting source metadata and mapping it to SharePoint columns (with unmappped attributes preserved as JSON if needed), using paged and differential export patterns to handle five‑digit document counts, and batching/parallelizing transfers while respecting API throttling. Where direct extraction to SharePoint was impractical for volume or performance reasons, the team recommended staging via Azure Blob Storage or similar, then ingesting into the SharePoint library. The solution set preserved key details needed for long retention (10 years), searchability, and future lookup, and provided the supportable transfer patterns (manual exports, automated flows, or API batch exports) appropriate to each source system and constraints.

New internal SharePoint and Communication sites, Teams‑connected workspaces, and team document libraries were provisioned to requester specifications and placed under the requested intranet sections or URLs; site and library links were provided to requesters and assigned owners. Where requesters required a dedicated document library that was managed manually (not auto‑updated by files posted in Teams), teams or libraries were created and configured to preserve manual management behavior; when a new Team was the simplest host for the library, a Team was created and named per request. Owners and site administrators were assigned admin rights when needed to populate content or manage access; requested members or groups were added and self‑join links were provided where appropriate. Visibility and security were set according to the request, including restricting access to managed groups and implementing nonstandard permission combinations (for example read+upload). Sites, libraries and workspaces were published/activated and added to intranet hub/global navigation when requested; naming and URL conventions (including organization prefixes such as IUG‑...) were applied for backups and policy checks. Requirement‑gathering meetings and owner walkthroughs, including live Teams demos, were scheduled or delivered to confirm expectations for site structure, permissions, and document collaboration. For content and page migrations, library content, images and PDFs were migrated and made available in the target site; where AvePoint or similar tooling was used, page moves were coordinated and scheduled with stakeholders. Complex or custom page elements routinely required post‑migration work: embedded SharePoint lists, SPFx or third‑party/custom web parts, and some configured widgets often needed re‑linking, reconfiguration, or recreation after migration; these limitations and remediation steps were documented and pilot/draft sites were staged for stakeholder review. For integrations and automated ingestion, dedicated service accounts were created and existing Microsoft Forms ownerships and Power Automate flows that ran under legacy/service accounts were reassigned or reconfigured; when content arrived from third‑party FTP providers or scanner/printer devices, document libraries were prepared, scanner/printer capabilities for direct scan‑to‑SharePoint were verified, and permissions or service account handoffs for network printers were arranged as required. Related shared mailboxes were created and follow‑up CareReport tickets were recorded where applicable. When further configuration details were requested, follow‑up calls or consultations were offered and documented outcomes were recorded in the ticket.

A production rollout of a single team-wide wiki was cancelled and no enterprise wiki was deployed. Support advised that the classic SharePoint 'Wiki' app was deprecated and recommended using modern SharePoint Site Pages (the Site Pages library) for wiki-like content; a requested page was copied from the Central Program Services site to the program site and confirmed working. For information stored in Excel and other fragmented sources, support arranged and held a requirements-gathering meeting (22.10.2024) in which a consultant presented implementation options combining SharePoint and other Microsoft 365 tools and captured clarifying requirements (for example target audience — students, staff, or both — and whether a dedicated intranet page was required). Preparatory design work evaluated a document-library-based wiki pattern using taxonomy managed in the SharePoint Term Store, leveraging crawled/managed properties and SharePoint search/indexing for filtering and search. Candidate components identified during design included a custom filter web part and the existing 'auronet Wiki Contents' app. Further design improvements and planning were deferred to a later quarter.

The support team confirmed that the built-in SharePoint/website-usage analytics and news export could not produce the requested historical, per-article metrics beyond their retention windows. The ticket documented that achieving the requirement would require external data consolidation via programmatic access (for example using Microsoft Graph / usage reports or Office 365 audit logs) or a third‑party analytics solution; the work was classified outside of the support scope (wont-do) and the ticket was closed.

Support declined to assist because the request involved a private/personal device outside the team's supported device policy. The ticket was closed as Done with the support response that configuration of personal devices was not supported.

The issue was resolved by correcting the page's Site Pages metadata: the Author field value referencing a former employee was cleared/replaced with a valid account, after which the page could be saved and edited successfully in multiple browsers. The fix targeted the missing/invalid required attribute on the specific page in the CPG_Human_Resource Site Pages library.

The issue was resolved by using SharePoint's Edit Grid View (Quick Edit) / multi-select editing to perform bulk updates to the Status choice field rather than attempting to use a right-click context menu. Records were selected in grid view and the Status column was updated en masse to "Published," eliminating the need to open each form individually.

The affected Loop workspaces were identified and relocated into the intended SharePoint Embedded containers. Administrators enumerated the impacted workspace IDs, corrected the tenant/site storage configuration that determined Loop provisioning, and migrated the listed workspaces into the Embedded container locations. Post-migration checks confirmed the workspaces resided in the Embedded containers and that ownership/permissions were retained.

Investigations found the affected SharePoint resources used permission scopes the requesting users did not have. Central IT or the site owner granted the missing scopes at the appropriate level (site, subpage, document library, or folder/DAM) and, in several cases, support applied access for the requester and relevant colleagues; after the permissions were applied users regained access and Salesforce/Teams/Care document views or uploads succeeded. Where a site owner governed the area, central support identified and engaged that owner because central support could not change those scopes directly. In one Fleet Management incident a metadata-driven automation that copied documents from a Teams channel preserved original access restrictions; resolution combined correcting the automation's copy/permission behavior and adjusting site-level permissions on the Teams-backed site (which had lacked intranet navigation and correct permission configuration). Several incidents followed billing/accounting or group-membership/tenant changes and were resolved either by administrative fixes or by automatic tenant/group sync restoring permissions. Permission changes typically required about 5–10 minutes to propagate. It was observed repeatedly that Teams channel visibility did not imply file-level SharePoint access because SharePoint enforces file/folder permissions separately from Teams channel membership.

Support clarified that submitting IT support tickets did not require SharePoint access and that users who could not reach SharePoint were directed to the Service Portal (accessible via myCampus or the Okta dashboard); the Okta URL was provided as an alternative route for opening tickets. For file-sharing needs involving external lecturers, support recommended creating a dedicated SharePoint site with external sharing enabled and bespoke permissions so links in the Freelancer/Partner Hubs worked for external users. Support noted that external users did not have access to internal SharePoint sites by default and offered to create and assist with the new site and its permission configuration.

A new SharePoint intranet hub/site was provisioned with the requested English default when the original site had German set as the immutable default; content migration was performed using AvePoint (Content Manager or Online Services) during approved backup windows. When migration jobs reported success but produced skipped, copied, or partially transferred content, technicians inspected and corrected job configuration/checkbox options and re-ran targeted migrations; items that were copied instead of moved were re-executed as move-not-copy jobs or re-migrated selectively. Instances where the tool showed aggregate moved counts but individual files (including .pptx) failed without appearing in the failed list were resolved by re-running the migration for the affected folders, re-migrating failed file types individually, or performing manual transfers for a small set of stubborn files; locked/checked-out files and conflicting placeholder folders were identified as causes and cleared or renamed before retrying. Missing subfolders and folders that appeared to exist but were empty were restored by re-executing the specific folder migration or manually copying content after removing destination-name conflicts. Pages with blank or wrong content rendered intermittently during migration were refreshed and, where necessary, remigrated; flagged wiki content was relocated into the Knowledgebase area and missing images were restored manually. Ownership and full edit permissions were granted to the requested users on destination sites. Large libraries with extensive file/version histories were migrated off-hours or on weekends and, where appropriate, executed as move-not-copy jobs to reduce runtime. Content Manager client failures on macOS were avoided by running migrations from Windows or via AvePoint Online. News-link failures were traced to browser popup blockers and were resolved by enabling popups in affected browsers. A follow-up appointment was scheduled to refine destination content and the original site was renamed to a temporary name pending final content decisions.

Support inspected the affected SharePoint list and mitigated the issue by restricting the numeric amount column's maximum allowed value to 200 via the column settings; after the max-value limit was applied the erroneous value inflation stopped for the impacted list. A separate, similar report recorded no final fix; that report documented diagnostic leads including mismatches in number-format/decimal-separator or locale/regional settings and the possibility of external automation (Power Automate) modifying the field. Both the applied max-value restriction (which prevented further incorrect values in the examined case) and the noted diagnostic leads were retained as unique resolution/triage knowledge.

Cross‑site calendar display was resolved by using one of two approaches depending on the desired behavior: (1) For a modern, Group‑backed calendar view the team treated the source as an M365 Group calendar, confirmed group ownership, added the destination site owners as members of that M365 Group to grant read access, and placed the Group Calendar web part on the target modern page. Site ownership ambiguity was cleared by reviewing the target site’s Site Permissions pane and updating the Site Owners list so a responsible owner could approve the display. (2) When the M365 Group calendar produced unwanted Teams channel posts and Outlook invites, the team created and configured a legacy SharePoint calendar in the SharePoint Classic Experience and embedded that calendar on the target page; the classic calendar was not tied to the M365 Group and avoided channel messages and meeting‑invite emails. Support staff also scheduled a meeting with the requestor to clarify requirements and perform the configuration collaboratively.

Support evaluated SharePoint, OneDrive for Business (SharePoint-backed), and Google Drive and provided options based on tenant capabilities. Where tenant/site external sharing was enabled, a SharePoint document library or OneDrive for Business had been used to create anonymous share links; replacing the file by uploading a new file with the same filename preserved the original public link. Google Drive also preserved a stable shareable URL when a new version was uploaded to the same file via its Manage Versions feature. Personal OneDrive accounts were noted as less suitable for official public distribution. In cases where organizational tenant policies disabled anonymous external sharing, SharePoint was ruled out and the Website Team hosted the handouts on a public web location so CRM email links could point to a central permanent URL. The team had also assessed audience and data sensitivity (public, non-sensitive slides) and determined that secure-file channels like SAFE were not appropriate for publicly distributed event handouts.

The team uploaded the new guide to the team's SharePoint/Intranet page and provided the direct SharePoint link to support. Developers updated the app configuration so the button pointed to the new SharePoint link, and a new app version containing the updated link was released and confirmed available.

When publication responsibilities were clear, stakeholders reviewed and approved the communication and IT published the message to the designated Teams channel or SharePoint News area on the agreed date (for example, aligned with a newsletter release). When ownership or content responsibility was unclear, IT confirmed the responsible team or person who must create the News post, advised that all post content needed to be prepared by that owner, and offered a 30‑minute walkthrough for creating and scheduling the post. Tickets were closed as Done when content owners did not respond after guidance and next-step expectations had been communicated.

The user re-recorded the meeting; the new recording contained audio and resolved the issue. The original failure could not be reproduced after the re-recording.

Tenant administrators verified that Delve / Office Graph had been intentionally disabled at the tenant level and confirmed that the limited SharePoint experience was expected behavior. Administrators decided not to re-enable Office Graph for security and policy reasons, informed the user of that decision, and provided alternative guidance about seeking administrative approval if a business case for enabling Office Graph existed.

The issue was resolved by consolidating ownership and locking down how data was edited: critical lists were migrated to Dataverse where row/field-level security was available and the default SharePoint form was replaced with a controlled PowerApps form that exposed only approved editable fields. For lists that remained in SharePoint, schema changes were restricted via content types and site/list ownership clarification, choice columns and SharePoint column validation were applied to reduce invalid entries, and list-level versioning was retained. A Power Automate flow was added to capture change events, notify owners of unexpected edits, and automatically revert harmful changes using the list version history when necessary. End-user guidance and a single-maintainer model for schema changes accompanied the technical controls.

No immediate technical fix was applied in the ticket. Support staff recorded the site usage (approximately 1.4–1.5 TB), confirmed there was no reproducible single-file failure sample, and escalated the situation to storage/capacity owners for archival, cleanup, or quota remediation decisions. The case remained documented for follow-up actions by the storage governance team.

Initial client-side troubleshooting (including testing in Microsoft Edge private mode and cross-browser checks) did not improve the symptoms. The incident was treated as a platform-level performance problem and was escalated to the tenant/platform service owners for deeper investigation of intermittent service degradation affecting SharePoint and Power BI; no client-side remediation resolved the issue during the documented troubleshooting.

Requests were resolved when SharePoint site owners or site administrators granted Edit permissions on the requested site and explicitly propagated or assigned those permissions to child subsites; access was verified and tickets were closed. Where a site owner was unknown or a Website Owner entry was missing, requests remained pending in the Automation for Jira approval workflow; support forwarded such cases to a specialist team, advised the requester to contact Site Page Owners, or helped identify the appropriate site owner. Frontline support repeatedly reported that they did not have site-administration privileges for restricted SharePoint areas and therefore could not assign permissions; in a few cases support later granted the requested editing rights but did not document the exact technical steps or the identity of the person who changed the permissions.

Support validated users' Access Denied or inability-to-edit symptoms and confirmed they did not have tenant- or site-owner privileges to change page-, page-section-, or site-level permissions. Investigations repeatedly found ownership or Full Control assigned to a specific owner account, closed/disabled mailbox, service account, or a former employee’s account. Support recorded that only the named site/page owner, the responsible office (for example an exams office), or the manager of the service account/mailbox had the authority to reassign permissions or grant edit rights. Where a service account or mailbox owned the resource, agents noted that credential or ownership changes required coordination with the teams that managed that account. In one observed case involving Microsoft Forms, administrators could not transfer Forms ownership while the original owner’s account remained active during offboarding; the transfer path required the owner account to be disabled per the offboarding process. Support requested site links or owner contact details when available, provided callers with these findings and next-step contacts, and performed no permission changes themselves; several tickets were closed after no further requester response.

A dedicated SharePoint site for HR was provisioned and the HR drive transfer was completed and verified. Secure site sharing settings were configured and site ownership and permissions were assigned (site owners listed in the ticket). These actions centralized HR documents into a controlled SharePoint site where access control and retention policies could be managed going forward.

The issue was treated as a list-level corruption/bug. A practical workaround that restored full view-edit functionality was to recreate the list (create a new list and migrate the items/columns) rather than attempting to repair the inherited view configuration. After recreating the list, users could open the Edit view dialog and modify filters, defaults, and advanced view settings again.