Comments
Excellent idea. I always think that this loading bar could be significantly improved by simply adding more indicator, or even a simple chevron. The current banner is too static and is not a good UX. The real-time part might not be feasible, but at least we can try to make the indicator more interesting and informative to the users.
Strongly support this improvement. The current dependency on a tested and enabled User/Queue mailbox creates unnecessary friction for customer-facing scenarios where communication is primarily with external contacts.In practice, this leads to inconsistent tracking behavior and reliance on workarounds like “Reply All,” which is not always appropriate. Enabling automatic tracking based on conversation context once the initial email is tracked would align much better with user expectations and significantly improve productivity and data completeness.This would be a meaningful enhancement for real-world customer communication workflows.
Strongly support this request. The current Default environment design works well for adoption, but it creates real governance gaps for enterprises.In practice, unrestricted access and automatic Environment Maker assignment often lead to uncontrolled app/flow creation and conflicts with managed environment strategies. Providing optional controls (such as security group restriction and role assignment management) would significantly improve alignment with enterprise governance without impacting the default experience for smaller or less regulated organizations.This would be a valuable enhancement to enable scalable and compliant adoption of the Power Platform.
Strongly agree with this suggestion. I’ve seen the same confusion multiple times from customers during evaluation.The current experience creates a disconnect between “what you can build” and “what you can actually validate end‑to‑end.” Customers are able to invest time building a Power Pages site in a Developer environment, but only later discover that key scenarios like custom domain configuration require a different environment type. This feels like a hidden constraint rather than an intentional design, especially for non-technical users.
From a support perspective, this gap creates unnecessary investigation effort and often results in cases being misinterpreted as product issues rather than expected limitations. It would be much clearer if the documentation explicitly explained the behavior and its dependency on rendering capabilities (e.g., email clients not supporting rich card formats consistently).Clarifying this upfront would significantly reduce confusion and improve customer experience.