Application for a Building Permit

This document describes an end-to-end building permit process, from planning to decision, for a Minecraft server. The applications concern what players are allowed to build in the Minecraft world (multiplayer), and the solution is designed to handle submission, case handling, AI-based assessment, and formal decisions in a structured and traceable manner.

The solution is built on the Microsoft Power Platform, Dynamics 365, Copilot Studio, Microsoft Foundry, and Microsoft Fabric.
Dataverse serves as the shared data foundation and single source of truth.

Problem Statement

On a Minecraft server with no rules, no zoning maps, and no building permit process, a player finally found the perfect place to build a cozy cabin: a bit of a view, some forest, far enough from spawn, and just the right amount of “wow.” He marked the area mentally, told himself “this will be home,” and logged off for five minutes to get coffee.

When he logged back in, the plot was gone.
Not because someone stole it—but because someone had built a FULL volcano there, complete with lava, smoke, a giant “WELCOME” sign, and a small obsidian temple on top.

The player was left standing with a bucket of water, a dream in flames, and the sudden realization: without rules, process, and traceability, “planning” is just a suggestion.

What We Want to Demonstrate

We want to demonstrate that it is possible to make building permit processing faster, more predictable, and more traceable—without losing control.

Enderdogs will demonstrate a coherent, end-to-end process:

• Area Planning
• Application
• Case Handling
• Decision

Area Planning with Minecraft Zones and Rules

The area plan establishes the framework for building in the Minecraft world through zoning and rule sets, for example:

• protected zones such as spawn areas, villages, temples, portals, or rare biomes
• designated building areas for private constructions or shared projects
• special rules such as maximum height, maximum footprint, distance to paths or rivers, or material requirements

Players may apply for plan changes by modifying zones or rule sets, or submit building applications within the current regulatory framework.

Application and Decision

When a building application is submitted, the following steps are executed:

• application submitted via Power Pages
• application data stored in Dataverse
• case handling performed in Dynamics 365 Customer Service
• AI used to validate requirements, documentation, and rules, as well as to perform risk assessment
• a formal decision is issued with justification and full traceability, approved or rejected

Technical Overview

Main Components of the Solution

1. Power Pages for application submission
2. Dataverse as the data platform and single source of truth
3. Dynamics 365 Customer Service for case management
4. Power Automate for workflow and automation
5. Copilot Studio for conversational support and guidance
6. Microsoft Foundry Agents for multi-agent evaluation and research
7. Microsoft Fabric and Power BI for insights and reporting

Data Model

• The data model is designed for traceability and extensibility.
• Core Tables in Dataverse
• Data Model (Dataverse) – High-Level Overview

Planning and Map Data

• adv_AreaPlan
  Area plan for the Minecraft world (framework, zoning, and rules)
• adv_Property
  Property/area on the map (Gnr/Bnr or plot), linked to AreaPlan and coordinates

Application

• adv_BuildApplication
  Building application submitted via Power Pages (building type, description, bounding box, status, applicant)

Requirements and Processing

• adv_ApplicationRequirement
  Requirement checklist for the application (documentation, rules, distances, etc.)
• adv_ReviewStep
  Case processing steps and status per step (received, validation, assessment, decision)

Actors

• Account / Contact (standard Dataverse)
  Used for players, server administrators, and optional moderators, including communication

Actors

Actors are modeled as accounts in Dataverse:

• server administration
• player / applicant
• optional moderator role for role separation and responsibility

Each account may have multiple contacts, with a primary contact for communication.

AI Support and Multi-Agent Assessment

The solution utilizes two AI layers with clearly defined responsibilities.

Copilot Studio

Copilot Studio is used for dialogue and operational support:

• portal agent for guidance during submission and completeness checks
• case handler support for summarization, checklist suggestions, and draft text generation

Microsoft Foundry Agents – Multi-Agent Evaluation

Microsoft Foundry Agents are used for structured evaluation of building applications. The agents operate as a team with specialized roles and deliver a consolidated decision basis.

Example Agent Roles:

• rules agent – evaluates compliance with zoning and building regulations
• placement and conflict agent – evaluates coordinates, distances, and conflicts with protected zones
• documentation agent – evaluates attachments, completeness, and consistency
• risk agent – evaluates deviations and factors requiring manual review
• decision agent – consolidates findings and produces a recommended decision with justification

Decision Types and Control Levels

The solution demonstrates three control levels:

• low risk: automatic decision with logged and traceable justification
• medium risk: AI recommends a decision; human decision-maker issues the final decision
• high risk: case is flagged and routed for manual handling

This is governed by policy, for example a risk score combined with fixed rules that always require human review.

Power Automate Flows

Automation binds the process together:

• submission creates a case and requirement checklist
• multi-agent workflow starts and writes recommendations back to Dataverse
• low-risk cases may be automatically decided and logged
• other cases are routed to a case handler with a complete decision basis
• notifications are sent for missing information and status changes

Analysis and Insights

Microsoft Fabric and Power BI are used for reporting and management insights, such as:

• number of submitted cases
• share automatically approved
• share flagged for manual handling
• most common reasons for rejection
• processing time per step

Appendix A – Solution Illustration

The illustration below shows the full lifecycle of the solution: area planning, political processing, neighbor notification, and decision.

Appendix B – Area and Zoning Map

The map below shows the area plan used in the POC. The area consists of multiple land and plot numbers (Gnr/Bnr) included in a shared area plan. The map forms the geographical foundation for zoning, neighbor notification, building applications, and visualization in Minecraft.

Legend:

• each color represents one property (adv_Property)
• the area is part of one area plan (adv_AreaPlan)
• purple areas represent proposed plots for leisure housing
• the map is used to determine neighbors, affected parties, and planning status

Link to Data Model and Process

• each property in the map is created as an adv_Property record in Dataverse
• when a property applies for rezoning or construction, neighbors are automatically identified