Posts

Boost Your Dashboards: The Role of Visual Calculations in Power BI

Image
Visual Calculations in Power BI play a transformative role by allowing users to write calculations directly within a visual, simplifying analysis and reducing the need for complex model-level DAX . Instead of creating reusable measures that affect the entire report, visual calculations work only inside the specific visual where they are defined, making them ideal for quick insights, prototypes, and visual-specific logic like running totals, moving averages, percent-of-total, rankings, and custom comparisons. They behave similarly to Excel formulas applied within a table, giving analysts more flexibility and reducing dependency on advanced DAX concepts such as context transition and CALCULATE . By running after the visual is rendered, these calculations adapt automatically to filters, drill levels, and slicers, delivering more intuitive, dynamic, and focused analytics. Power BI introduced Visual Calculations (preview feature) to make analytics more intuitive, dynamic, and easier to wri...

Behind the Names: Unlocking Schema and Logical Names in Dataverse

Image
Schema and Logical Names in Dataverse form the backbone of how data is structured, stored, and referenced within the platform. The Schema Name is a system-level, immutable identifier created when a table or column is generated; it is mainly used by developers, plugins, integrations, and API calls. It follows a strict format (prefix + name) and does not change even if the display name changes, ensuring long-term stability for solutions and custom code. The Logical Name , on the other hand, is the programmatic name Dataverse uses internally and externally when accessing data through the Web API, SDK, Power Automate, or Power Apps. Logical names are unique and aligned to the physical storage in the Dataverse database. While schema names provide structure and a consistent metadata definition, logical names enable efficient data operations and integration. Together, they create a reliable separation between user-friendly labels and system-driven identifiers, ensuring stability, consistency...

From Backlog to Delivery: Running Scrum in Azure DevOps

Image
This is a practical, end-to-end guide to run Scrum with Azure DevOps — from backlog grooming through sprint delivery and continuous deployment. It blends Scrum practices with Azure DevOps features (Boards, Repos, Pipelines, Test Plans, Artifacts) so your team can deliver predictably and iterate quickly. 1 — Foundations: Roles, artifacts & mapping to Azure DevOps Scrum roles Product Owner — owns Product Backlog (Azure Boards: Product Backlog view / Epics, Features, Product Backlog Items). Scrum Master — facilitators, removes impediments, enforces process. Development Team — implements work, updates Azure Boards, creates branches/PRs, runs pipelines. Key Scrum artifacts → Azure DevOps Product Backlog → Work Items: Epics → Features → Product Backlog Items (PBIs) / User Stories Sprint Backlog → Iteration backlog (sprint iteration path) Increment → Builds/Artifacts + Release pipeline deployment (Environments) Work item types & fields Use default or customized types: Epic → Feat...

Rules of Engagement: How Plugins, Workflows, and Power Automate Coexist in the Execution Pipeline

Image
Understanding how the three automation engines interact—Plugins, Classic Workflows, and Power Automate—is essential for designing predictable, scalable, and conflict-free business logic in the Power Platform. Each automation type runs at different layers, at different times, and with different capabilities. When combined without rules, they create race conditions, duplicated logic, inconsistent data, and performance issues. This guide explains when each tool executes, what they are best suited for, how to avoid conflicts, and how to design the execution pipeline properly. 1. The Dataverse Automation Stack – High-Level View 2. What Runs Where? (Rules of Engagement) A. Plugins — “First Responders” (Synchronous or Asynchronous) Where they run:  Deep inside the Dataverse execution pipeline  Before or after the database commit Best for: Real-time validation Enforcing business rules Data transformation Preventing bad data from saving High-performance logic Complex parent/child relat...

Pipeline-First Thinking: Designing Robust Business Logic in Dataverse

Image
In Microsoft Dataverse, every data operation—whether triggered by a form save, API call, plugin, or Power Automate flow—passes through a well-defined execution pipeline. Understanding this pipeline is not just a technical detail; it is the foundation for designing scalable, predictable, and maintainable business logic. This approach is called Pipeline-First Thinking, and it is a mindset every Power Platform architect and senior developer must adopt. What Is Pipeline-First Thinking? Pipeline-First Thinking means designing your custom logic based on where and how Dataverse processes your data. Instead of jumping directly into writing plugins or creating Power Automate flows, you first analyze: Which stage of the pipeline should run the logic? (Pre-Validation, Pre-Operation, Post-Operation, Async, etc.) What data is available at each stage? How will the logic behave inside a transaction? What are the impacts on performance, validations, and external integrations? By aligning business rule...

Why Understanding Plugin Execution Pipeline is Critical in Power Platform

Image
The Plugin Execution Pipeline is the sequence of events Dataverse/Power Platform runs when an operation occurs (Create, Update, Delete, SetState, Retrieve, etc.). Plugins are custom code that run inside that pipeline. Understanding how the pipeline works is fundamental for building correct, secure, performant, maintainable, and supportable solutions. Below I explain what the pipeline is, how it behaves, why it matters, common pitfalls, and practical recommendations. What the execution pipeline is — the essentials When an operation is invoked, Dataverse constructs an IPluginExecutionContext and executes registered plugin steps in the order defined by: PreValidation (before core platform validation) PreOperation (inside the database transaction, before platform operation) Platform Operation (the core create/update/delete that modifies the DB) PostOperation (after the platform operation, still part of the request but after DB change) A plugin step registers the Message (e.g., Update), Pri...

Bridging Dataverse and External APIs with Custom API

Image
Modern business applications rarely operate in isolation. Organizations increasingly need their Microsoft Dataverse environments to interact with external systems such as CRMs, ERPs, banking systems, SAP, ServiceNow, payment gateways, logistics platforms, or AI-enabled services. Custom API in Datavers e acts as the perfect bridge—a controlled, secure, and scalable layer that connects Dataverse to external APIs.  What Does “Bridging Dataverse and External APIs” Mean? To “bridge” Dataverse with an external API means: Dataverse triggers a process (from a plugin, Power Automate, Canvas App, Model-Driven App, or even external systems) Custom API receives the request Custom API executes server-side code (Plugin) written in C# The code makes an outbound call to an external REST/SOAP endpoint Returns the processed result back to Dataverse , or updates records This creates a secure, governed, and high-performance integration layer—without exposing Dataverse directly to outside systems. Wh...