Word/PowerPoint are not suitable replacements for Publisher
I’m writing following the guidance that Word and PowerPoint can be used as replacements for Publisher. This feedback is based on completing a real production document, not theoretical use Having just completed a fairly complex, layout-heavy technical document, I thought it only fair to share how that works in practice. In theory, I can see the logic: Word handles documents PowerPoint handles layouts Therefore, between the two, everything should be covered Unfortunately, in reality, this appears to be more of a theoretical exercise than a practical solution. Publisher was clearly designed for: Fixed, page-based layouts Precise positioning of objects Efficient alignment of mixed content (text, images, tables) Producing consistent, professional multi-page documents By comparison: Word is admirably committed to reminding you that it would prefer everything to flow freely, regardless of whether you want it to or not PowerPoint, while better behaved, does seem to assume every page is a standalone slide rather than part of a structured document Both tools can, with enough persistence, be persuaded into doing the job. However, this involves a level of manual intervention, workaround, and general negotiation with the software that feels somewhat at odds with modern productivity software. To put it simply: They are not replacements in any meaningful, real-world sense. The end result can be achieved, but the process is unnecessarily time-consuming, fragile, and prone to unexpected layout changes—particularly when precision actually matters. Replacing a purpose-built publishing tool with two applications that were never designed for that role gives the impression that this use case has been… optimistically simplified. I would strongly encourage Microsoft to either: Provide a genuine page-layout solution within the Office suite, or Enhance existing applications so they can support fixed-layout publishing without constant workarounds At present, the gap left by Publisher is very noticeable for anyone producing structured documents beyond basic text. I appreciate the direction of Microsoft 365 overall, but in this particular area, the experience feels less like an evolution and more like working around a missing tool. Regards Andy
Clarification on SharePoint Macro Consent Flow and Permissions
Hi Team, We have a customer using SharePoint in a secure environment. While configuring the Prolaborate SharePoint Macro on their site, a consent popup is displayed during the approval process. Previously, our macro implementation used the Admin Consent flow. Based on the customer’s security and approval requirements, we have modified the consent to use the User Consent flow instead. The customer has requested additional clarification regarding the consent process. Specifically, they would like to understand: The exact API calls triggered for these two consents View your basic profile Maintain access to data you have given it access to The permissions being requested from Microsoft Graph or SharePoint Whether the application requests any tenant-wide or high-privilege permissions Whether minimal permissions such as Sites.Selected can be used instead of broader scopes Current concern: The customer feels the current permission request is too broad for approval within their secure environment (Banking customer). Reason: Their internal approval process requires clear visibility into the exact API and permission scopes being requested, as different permissions are reviewed and approved by different internal teams (for example, User.Read is managed by the Identity team). From our implementation side, we are using only custom APIs and are not directly calling Microsoft Graph APIs. This information will help us provide a clear response to the customer and support their internal approval process.
Struggling with running DQ Scans (Long queuing and Retry Count Error Issues)
Hi everyone, I have been exploring Microsoft Purview Data Quality quite extensively. At this point, I have configured more than 4,000 data quality rules across more than 10 Microsoft Fabric capacities, each with a minimum capacity of F16. Fabric is the source for all assets registered in Purview. I have identified several issues with the product, but the two that are currently impacting me the most are the following: DQ scans failing with a generic error“Max Retry Count Reached. Ending Workflow. Current Task HandleError”The challenge is that the error message does not identify which rule is causing the failure. As a result, I have to troubleshoot manually by disabling groups of rules, rerunning the scans, and repeating the process until I find the problematic rule. This trial-and-error approach is very time-consuming, especially at this scale. This seems to be caused by issues in some of the DQ rules, even though all rules are marked as “Good to go” in Purview. When running Data Quality scans, I often receive the following error: DQ scans remain queued for a long timeI am not sure why this happens or what resource, orchestration, or scheduling constraint is causing the delay. Whenever I run these DQ scans, they remain in a Queued state for at least 10 minutes, even when there is nothing running on the Fabric capacities. Has anyone experienced similar behavior with Purview Data Quality at this scale? Specifically, I would appreciate any guidance on: How to identify which DQ rule is causing a scan failure Why scans remain queued even when Fabric capacity appears to be idle Whether there are known limitations or best practices for running thousands of DQ rules in Purview Thank you.Clarity at every stage: App Advisor turns Marketplace complexity into action
For software development companies, the Microsoft Marketplace journey isn’t always linear. It’s a series of decisions: what to build, how to package it, how to publish, and how to sell it, each with real dependencies and real friction.Solutions for document-centric business processes - Portal Systems - SharePoint Partner Spotlight
We are excited to share a new episode on our partner showcase series focused on SharePoint in Microsoft 365. In this post, we focus on Portal Systems which is providing document management solutions for Microsoft 365, built with SharePoint Framework (SPFx).Proven intranet framework - Involv Intranet - SharePoint Partner Spotlight
We’re excited to share a new episode in our partner showcase series focused on SharePoint in Microsoft 365. In this episode, we spotlight Involv Intranet and how it brings a modern intranet experience to life using the SharePoint Framework (SPFx).Business Applications Built for Microsoft 365 – Cubic Logics – SharePoint Partner Spotlight
Discover how Cubic Logics is helping organizations transform Microsoft 365 into a business application platform. With over 12,100 deployments in 172 countries, their Apps365 solutions bring HR, contract management, help desk, asset management, and AI-powered experiences directly into the flow of work across Microsoft 365.
