The bulk of the work was completed in the first round. In the second, I added the minimum and maximum boxes, and in the third, I added the requirement that the entire history of the reviewers’ comments appear in the Review box.

I opted to go through the entire Spec Kit process even for the smaller features, which I admit was a bit slower than I would have liked. But all in all I got a starter front end that, again, would have taken much longer, especially since I don’t know Blazer (though I know a good bit more now, having read through the code and documentation).

I ended up with at least a dozen .razor files and twice as many bootstrap.js (and .min.js) files. Copilot told me how to fire it up and what port it would appear on. By starting the application in the terminal, I could watch all my logging and tracing go by, though I added the logging to the bottom of the page (right now it is in a scrolling box, but I think I’ll change it to display just one line at a time—not sure about that.)

My experience was excellent, but I did notice that it was eating a lot of tokens. From the time I started the work until I was done, it had consumed about 10,000 tokens! (ouch)

The first step was to create a specification, saying what I wanted to build. (I reused the existing Constitution).

Replace the local JSON-only session store with a Cosmos DB for NoSQL-backed IBlogSessionStore implementation. Persist each complete BlogSession under its signed-in Microsoft Entra object ID, expose a console command that lists the owner’s 20 newest sessions, and retain the existing resume <session-id> and follow-up workflows. Use optimistic concurrency so a stale client cannot overwrite a newer saved session.

Actually, even that statement was written by Copilot. My initial statement was a bit sparser. In any case, with that in place, I could write my plan. When I did so, Spec Kit asked a number of clarifying questions to make sure it knew exactly what I wanted.

Q: How should the application identify the owner of each saved session?

It created a series of User Stories to ensure that I agreed with the acceptance criteria. With that done, it created a series of phased tasks and their implementation dependencies (e.g., you can’t do User Story 2 until you’ve finished the work for User Story 1).

I’m simplifying because this was covered in the previous blog post.

Spec Kit documented the research it did and the decisions it made, along with its rationale.

Decision: Reuse a single Cosmos client and use asynchronous APIs

Rationale: Reusing the client avoids connection churn, and asynchronous cancellation-aware operations match the existing store contract. Cosmos SDK retry behavior handles transient throttling; conflict responses remain user-actionable and are not retried as writes.

Alternatives considered:

• Construct a client per operation: adds latency and risks socket exhaustion.
• Retry every write: may hide stale-write conflicts and violate the specified reload behavior.

It was ready to list the tasks that would break down the work to be done. As part of creating the tasks, it created tasks.md, which listed what had to be done and which would contain boxes to check off as it proceeded.

Very cool. I set it free to write the code. It touched or added 17 files, not counting the documentation. It took a while to review all that code, but it was very well commented, and I didn’t have to make any changes.

I then asked it to provision a Cosmos database on Foundry, which it did, using my pre-existing resource

With this, I can observe the entries into the database. For each entry I can get the search request and its related metadata

It also added the “list” prompt to the console. When I click list, it displays the last 20 (configurable) queries.

All of this took two to three hours—and then only because I carefully read all the code as I went (and took one or two phone calls and made a cup of coffee). I would guess that this represented a 5-10x productivity improvement. And I ended up with extensive documentation, better than I could (or would) have written myself.

Next step: right now to resume a session, you have to enter the session ID (a GUID). I will have it number the entries (e.g., [1]) and then recall that session based on that number.

I love programming; I’ve been doing it for over 30 years (Assembly, C, C++, C#) but I don’t imagine I’ll be doing much keyboard banging any more. Yes, you need to know the language and idioms to check the code, but with this kind of productivity improvement it seems irresponsible to cling to the old way of creating applications.

Statement of the week related to the above: No one ever wanted a ½” drill bit. What they want is a ⅛” hole.

Followup

I grew impatient, so I put in another hour’s work with Spec Kit and Copilot and implemented the feature allowing the user to pick a number from the list and hiding the GUID

Click one of the bracketed numbers, and that search becomes current. You can then run it again or modify it (and the database will update to reflect the modification).

[For more on the steps in SDD, please see what I wrote about Spec Kit previously.]

Today I fired up Spec Kit and pointed Copilot at it, instructing Copilot to create a constitution based on the existing code (my blog writing demo). A minute later I had a comprehensive document that listed all the immutable characteristics of the application. It was quite long, but here is the beginning:

Hosted-Agent Boundaries

The console application is responsible for workflow orchestration and session handling. Blogger, Researcher, Author, and Reviewer remain independently deployable Azure AI Foundry Hosted Agents. The console must communicate with them through Microsoft Agent Framework abstractions and must not issue ad hoc raw HTTP calls or recreate their model logic in-process.

Other sections include:

• Microsoft Agent Framework-Native Workflow Composition
• Identity, Secrets, and Budget Control
• Testable and Observable Behavior
• Simple, Compatible Evolution
• Technical Constraints
• Development Workflow
• Governance

Specify

With that in hand, I wrote a basic specification of what I wanted to build, and Copilot worked with Spec Kit to turn it into a specification document (in about 5 seconds). I wrote:
Add long-term memory using Cosmos so that we can store what is currently in the session to allow listing of previous questions and allow follow-up

Spec Kit turned that into a full specification and identified a series of questions that needed clarification. It presented each to me with multiple-choice answers, including the ability for me to add a custom choice. For example, one area that needed clarification was:

Q: What should happen to saved sessions when a user leaves the organization or their Entra account is deleted? -> A: Automatically delete sessions when the account is deleted.

The specification also included:

• A series of user stories with their acceptance criteria
• A List of edge cases
• A list of functional requirements
• A list of key entities
• A list of success criteria with measurable outcomes
• A list of assumptions

And so it went through the various stages of SDD. It created a comprehensive plan for my approval and then wrote out all the tasks to implement that plan. As it went, it checked off each item in the task list, driven by unit tests.

When I was done, I had a fully working, fully documented new feature that would, in the past, have taken three days and today took two or three hours. And the only reason it took that long was that I was carefully checking its work, which was nearly flawless.

For details, I recommend reviewing the code for the demonstration application.

More on this to come…

Click here

This article explains the runtime mechanics (what happens when a workflow asks a human for input), the developer experience (what you write), concrete examples (C# + JSON contracts), integration patterns with Bot Framework/contact centers, failure modes, and testing strategies.

A concise scenario
An LLM suggests a $50,000 refund to a customer. If your automation approves it automatically you risk fraud and compliance violations; if you block it you frustrate customers and increase manual work. The correct middle ground is a durable, auditable workflow that pauses, sends a precise task to a human reviewer, and reliably resumes once the reviewer responds. Microsoft Agent Framework makes that pattern a core primitive instead of an ad‑hoc add‑on.

Overview: what Agent Framework gives you for HITL

• Typed RequestPorts: define strongly typed request and response schemas so humans and automation agree on payload shapes.
• Durable suspend/resume: when an executor issues a request, the workflow branch is suspended durably until a response arrives (survives restarts).
• RequestInfoEvent emission: the framework emits a structured event the agent hub or any subscriber can consume to present tasks to humans.
• Automatic routing & correlation: responses include metadata that the framework uses to match the response to the exact waiting executor, avoiding much manual correlation code.
• Orchestration & handoff primitives: the workflow language supports approval nodes, escalations, timeouts, and integration points for agent hubs or contact centers.

Request lifecycle: step‑by‑step

Declare RequestPort(s) in the workflow

• A RequestPort is a typed channel (request type, response type). Example: RequestPort.

Executor issues a request

• Inside an executor (HandleAsync or equivalent), the code calls the framework API (e.g., context.SendRequestAsync) to send the request payload. The call returns only when the response is received or the request is cancelled/timeout occurs.

Workflow branch is suspended

• The framework persists the suspended state. The executor essentially awaits the response; the workflow instance remains durable in storage (so node restarts or transient failures won’t lose the wait).

RequestInfoEvent is emitted

• The framework publishes an event that includes request metadata, the typed payload, timestamps, TTL, and any contextual fields the workflow author supplied. External systems subscribe and surface the task to human operators.

Human reviews and posts a response

• The human operator uses an agent hub UI (built-in or custom) to inspect context and submit a response. The agent hub posts the typed response back to the Agent Framework through a Response Ingest API or SDK call.

Framework routes response back to waiting executor

• Using request id + workflow instance id (and port name/type), the framework finds the suspended executor and delivers the typed response. The executor resumes and the workflow continues.

Developer view: what you author
At a high level you:

• Define RequestPorts and response types.
• Write executors that call context.SendRequestAsync (or RequestPort.Send).
• Subscribe to RequestInfoEvents or integrate Event Grid/Service Bus to route tasks to your agent hub/UIs.
• Implement a response ingest endpoint (secured) that posts typed responses back to the framework.

Concise C# worked example (end‑to‑end sketch)
Below is a minimal, runnable‑style illustration (API names adapted to the docs’ conceptual forms). This shows the RequestPort declaration, the executor sending a request, emitting an event handled by the agent hub, and the response ingest flow.

1) Define request/response types
public record ContentModerationRequest(string Content, string UserId, string ConversationId);
public record ContentModerationResponse(bool Approved, string ReviewerId, string Notes);

2) Create a RequestPort and wire into a workflow
var contentModerationPort = RequestPort.Create(“ContentModeration”);

var workflow = new WorkflowBuilder(contentModerationPort)
.AddEdge(inputSource, contentModerationExecutor)
.AddEdge(contentModerationExecutor, continueExecutor)
.Build();

3) Executor sends request and awaits response

internal sealed class ContentModerationExecutor : Executor
{
   public override async ValueTask HandleAsync(ContentItem message, IWorkflowContext context, CancellationToken ct)
   {
      var request = new ContentModerationRequest(message.Text, message.UserId, message.ConversationId);
    // SendRequestAsync emits a RequestInfoEvent and suspends until the human response arrives
    ContentModerationResponse response = await context.SendRequestAsync(contentModerationPort, request, ct);

    if (response.Approved)
    {
        // proceed with publishing, optionally using edited content from notes
        await context.ScheduleAsync(new PublishMessage(response.ReviewerId, message.Id), ct);
    }
    else
    {
        // handle rejection path
        await context.ScheduleAsync(new NotifyUserDecline(message.UserId), ct);
    }
  }
}

Notes:

• SendRequestAsync returns a typed response object (ContentModerationResponse) when the human submits their decision.
• While awaiting, the workflow’s state is persisted so the process is durable.

Agent hub responsibilities and the RequestInfoEvent
When SendRequestAsync is called, the framework emits a RequestInfoEvent. The agent hub subscribes (Event Grid, Service Bus, or a SDK event callback) and must implement:

• Task display: show request details, provenance (workflow id, request id), attachments, and relevant context (conversation transcript, policy guidance).
• Claiming model: accept/claim or pick-from-queue semantics to avoid double-work.
• Response posting: a secure call to the Response Ingest API that returns success or a clear error (with appropriate HTTP status codes).

Sample RequestInfoEvent payload (JSON)
{
“requestId”: “req-abc123”,
“workflowInstanceId”: “wf-987”,
“portName”: “ContentModeration”,
“requestPayload”: {
“content”: “AI-generated reply…”,
“userId”: “user-42”,
“conversationId”: “conv-77”
},
“createdAt”: “2026-09-14T12:34:56Z”,
“ttlSeconds”: 3600,
“metadata”: { “priority”: “high”, “origin”: “chatbot-01” }
}

Response ingest contract (what the agent hub posts back)
POST /api/agent/responses
Headers:
Authorization: Bearer
Body:
{
“requestId”: “req-abc123”,
“workflowInstanceId”: “wf-987”,
“responsePayload”: {
“approved”: true,
“reviewerId”: “agent-007”,
“notes”: “Approved; removed PII”
},
“submittedAt”: “2026-09-14T12:40:01Z”
}

Expected responses:

• 200 OK — response accepted and routed to the executor.
• 400 Bad Request — malformed payload or schema mismatch.
• 404 Not Found — request id not found (possibly expired or already completed).
• 409 Conflict — duplicate or conflicting response (depending on your policy).
• 410 Gone — request timed out or was cancelled.

Correlation, routing, and metadata best practices
What the framework provides:

• requestId: unique per request invocation.
• workflowInstanceId: identifies the workflow instance.
• portName (and port type): identifies the RequestPort.
  With those, most routing is automatic. Practical guidance:
• Always include requestId in your response ingest calls. requestId is the primary, unambiguous handle for routing.
• Port name/type adds another safety layer, useful if your agent hub sees many types of requests.
• Capture and surface workflowInstanceId in the agent UI for audit and troubleshooting.
• Store and emit reviewer identity and timestamps in responses for compliance.

Handling duplicates, late responses, and concurrency

• First‑wins vs quorum: by default a single response satisfies the waiting executor. If you need multiple approvals or consensus, model it explicitly—create multiple RequestPorts or a response type that supports aggregation and implement quorum logic in the workflow.
• Duplicate submissions: agent hub should make the ingest POST idempotent. The server should accept the first valid response and return 409 or 200 for subsequent duplicates, depending on your semantics.
• Late arrivals: responses for cancelled or timed‑out requests should be rejected with 410 Gone and the agent hub should surface a clear explanation and allow re‑issuing (create a new request).
• Concurrency: if two human agents submit different responses simultaneously, the framework decides based on request id ordering; design the workflow to verify critical transitions—e.g., accept only responses signed by an approver role, or require a reconciliation step.

Timeouts, fallbacks, and alternate flows
Long human latency blocks user experience. Your workflows should:

• Configure sensible TTLs on RequestPorts (e.g., 30m for routine approvals, 24h for slower approvals, two minutes if the user is on hold!).
• Define fallback flows for timeouts: reassign to escalation queue, auto‑approve/deny under defined policies, or create a notification to a manager.
• Emit interim events (e.g., “pending too long”) to monitoring and alerting systems.

Orchestration patterns: single approval, parallel approvals, and SAGA compensation

• Single approval: the workflow issues one request and continues when it receives a single response.
• Parallel approvals (n of m or quorum): create multiple requests in parallel and wait for N responses or a consensus step. Example:
• Spawn three RequestPorts (or the same port with multiple request instances) and gather responses. Resume when at least two are approvals.
• SAGA / compensation: if the human rejects a step that has already triggered side effects, model compensating actions in the workflow (reverse a debit, revoke a provisional publish). Combine timeouts with compensation to avoid leaving inconsistent state.

Integrating with Bot Framework and contact centers
Agent Framework HITL and Bot Framework are complementary:

• Bot as trigger: a conversational bot collects context and triggers a workflow that may create a RequestPort task for human approval.
• Bot as proxy: once a human accepts, Bot Framework’s handoff patterns (bot-as-proxy) can connect a human agent into the live conversation while the workflow continues to manage business-level approvals.
• Agent hub integration: use Omnichannel for Dynamics or an agent hub service to surface tasks to Teams, Dynamics agents, or third‑party contact centers.

A concrete flow (bot + Agent Framework + Teams)

1. Bot collects issue and calls a workflow API to start a warranty claim workflow.
2. Workflow evaluates risk. If high, it calls SendRequestAsync on a ClaimApprovalRequestPort.
3. The Agent Framework emits RequestInfoEvent and routes it to Event Grid.
4. Event Grid forwards to an agent hub that posts a message in a Teams queue or Dynamics Omnichannel.
5. An agent reviews in Teams, submits the approval via the agent hub (which calls the Response Ingest API).
6. Agent Framework resumes the workflow and posts the outcome back to the bot (or directly to the user).

Security and compliance

• Authentication: secure the Response Ingest API with OAuth 2.0 (Azure AD Bearer tokens) or mutual TLS. Agent hub should authenticate as a service principal with least privilege.
• Authorization: enforce RBAC so only authorized roles can approve certain request types (finance team for refunds).
• PII removal: redact or mask sensitive fields in RequestInfoEvent payloads and in agent UIs. If full PII is required, limit retention and access logs.
• Audit trails: persist request/response payloads, reviewer identity, timestamps, and any changes. Use immutable storage or append‑only logs for compliance.

Observability and operational metrics
Track and alert on:

• Pending request count per port.
• Average and P95 human response time.
• SLA (Service Level Agreement) breaches (e.g., pending_response_time > SLA).
• Request churn (creates, cancels, re‑issues).
• Approval rates and reviewer throughput.

Note P95 indicates 95th percental latency between when a task is presented to a human and when they respond.

Suggested alerts:

• Pending requests > threshold for > X minutes (escalate).
• Average response time rising > 2x baseline (investigate agent hub throughput/availability).
• Rejected requests spike > typical baseline (potential model drift or policy change).

Testing and CI/CD strategies

• Unit testing executors: mock SendRequestAsync to simulate human responses and assert branching logic.
• Integration tests: test full path — executor sends request → event emitted → simulate agent hub response → workflow resumes.
• Load testing agent hub: simulate spikes of RequestInfoEvent to confirm queueing behavior and UI scaling.
• Chaos testing: simulate delayed responses, duplicate responses, and timeout conditions to verify fallback flows and compensation logic.

Common pitfalls and how to avoid them

• Missing context in the agent UI: always surface the workflowInstanceId, requestId, and relevant transcript attachments. Humans need context to make fast decisions.
• Assuming low latency: design timeouts and fallback behavior; don’t block user interfaces waiting indefinitely.
• Weak correlation design: require requestId in responses. Avoid relying on human-entered identifiers that can be mistyped.
• Lack of auditability: store reviewer identity and notes; consider signing responses or using immutable logs for compliance.

I wanted to allow the user to refine the search after getting the draft. To do so, I needed short term memory. Here are the changes I made…

I implemented the search refinement flow by updating the research state and wiring it into the research step:

• In ResearchState.cs, I added:
  • CurrentSubTask to represent the newest follow-up request
  • SearchRefinements to keep the history of prior refinement requests

SearchRefinements is a list<string>. As the ResearchState is created the code checks to see if there are refinements. If so the new refinements are appended to the existing request

       if (SearchRefinements.Count > 0)
        {
            string uniqueRefinements = string.Join(" | ", SearchRefinements
                .Where(r => !string.IsNullOrWhiteSpace(r))
                .Distinct(StringComparer.OrdinalIgnoreCase));

            if (!string.IsNullOrWhiteSpace(uniqueRefinements))
            {
                parts.Add($"Refinement history: {uniqueRefinements}");
            }
        }

• BuildResearchQuery() to assemble a single, richer research prompt that includes:
  • the original task
  • the active follow-up refinement
  • previous refinement history
  • prior research findings/context
• StartFollowUp() to preserve the existing draft/research state while resetting the review cycle and recording the previous subtask as a refinement

   public void StartFollowUp(string followUp)
    {
        ArgumentException.ThrowIfNullOrWhiteSpace(followUp);

        string trimmed = followUp.Trim();
        if (!string.IsNullOrWhiteSpace(CurrentSubTask) &&
            !string.Equals(CurrentSubTask, trimmed, StringComparison.OrdinalIgnoreCase))
        {
            SearchRefinements.Add(CurrentSubTask.Trim());
        }

        SearchRefinements.Add(trimmed);
        CurrentSubTask = trimmed;
        ReviewNotes = "";
        RevisionNumber = 0;
        NextStep = "";
    }

• In ResearcherAgent.cs, I changed the research node to use state.BuildResearchQuery() for each research pass, so the agent searches with both the original goal and the refinement history instead of starting from scratch.

    public string BuildResearchQuery()
    {
        var parts = new List<string>();

        if (!string.IsNullOrWhiteSpace(MainTask))
        {
            parts.Add($"Original task: {MainTask.Trim()}");
        }

        if (!string.IsNullOrWhiteSpace(CurrentSubTask))
        {
            parts.Add($"Follow-up refinement: {CurrentSubTask.Trim()}");
        }

        if (SearchRefinements.Count > 0)
        {
            string uniqueRefinements = string.Join(" | ", SearchRefinements
                .Where(r => !string.IsNullOrWhiteSpace(r))
                .Distinct(StringComparer.OrdinalIgnoreCase));

            if (!string.IsNullOrWhiteSpace(uniqueRefinements))
            {
                parts.Add($"Refinement history: {uniqueRefinements}");
            }
        }

        if (ResearchFindings.Count > 0)
        {
            string context = string.Join("\n\n", ResearchFindings
                .Where(f => !string.IsNullOrWhiteSpace(f))
                .Select(f => f.Trim()));

            if (!string.IsNullOrWhiteSpace(context))
            {
                parts.Add($"Prior research context:\n{context}");
            }
        }

        return string.Join("\n\n", parts);
    }

• In ResearchStateTests.cs, I added coverage confirming that:
  • a follow-up preserves the original task
  • the refinement is included in the generated search query
  • earlier research context is retained

   [Fact]
    public void StartFollowUp_PreservesDraftAndResearchButResetsReviewCycle()
    {
        var state = new ResearchState
        {
            MainTask = "topic",
            ResearchFindings = ["finding"],
            Draft = "draft",
            ReviewNotes = ResearchState.ApprovedMarker,
            RevisionNumber = ResearchState.MaxRevisions,
            NextStep = "END",
        };

        state.StartFollowUp("Add a caching section.");

        Assert.Equal("Add a caching section.", state.CurrentSubTask);
        Assert.Equal("draft", state.Draft);
        Assert.Equal(["finding"], state.ResearchFindings);
        Assert.Empty(state.ReviewNotes);
        Assert.Equal(0, state.RevisionNumber);
        Assert.Empty(state.NextStep);
    }

    [Fact]
    public void BuildResearchQuery_IncludesOriginalTopicAndFollowUpRefinement()
    {
        var state = new ResearchState
        {
            MainTask = "How to build a blog app",
            ResearchFindings = ["Concepts: context, prompts, and workflow.", "Drafting is done after research."],
            CurrentSubTask = "Add a caching section."
        };

        string query = state.BuildResearchQuery();

        Assert.Contains("How to build a blog app", query);
        Assert.Contains("Add a caching section.", query);
        Assert.Contains("Concepts: context, prompts, and workflow.", query);
        Assert.Contains("Drafting is done after research.", query);
    }

Why this enables refining a search

The crucial behavior is that a follow-up no longer discards the earlier work. The generated query now looks like:

• Original task
• Follow-up refinement
• Prior refinement history
• Earlier research findings

That means the next search is “narrowed and contextualized” rather than replaced, which is the actual refinement behavior you were asking for.

Copilot and I fixed this with the following changes:

Refined follow-ups now reset stale state so the workflow re-enters research instead of reusing old draft/research data.

Updated in ResearchState.cs:80-105
This clears the draft, research findings, review notes, and revision state before the next run.
The blogger routing now correctly sees “no research” after a refinement and sends the next step back to the researcher.

The logic is in BloggerAgent.cs:24-68
The behavior is covered by BloggerAgentRoutingTests.cs:34-58
The researcher’s console output now prints the full query, including the original task and the follow-up refinement, rather than just the bare subtask label.

Updated in ResearcherAgent.cs:69-84
We also added regression tests for both the reset behavior and the routing behavior:

This cycle of using Copilot to generate code and tests, reviewing that code, posting a PR to GitHub, getting back feedback from Copilot and, as needed, making revisions and creating another PR is a powerful development cycle.

For more on this see Copilot Code Review

tl;dr
An Azure tenant — now called a Microsoft Entra ID tenant — is a dedicated, isolated instance of Microsoft’s identity service that represents an organization’s identity and access boundary. It’s the directory that stores users, groups, applications and their credentials, service principals, roles, and policies used to authenticate and authorize access to resources and apps.

Why the distinction matters
People often confuse “tenant” with “subscription.” They are different:

• Tenant (Microsoft Entra ID): an identity and access container. It owns the directory objects (users, groups, app registrations, service principals, directory roles, conditional access policies).
• Subscription: a billing and resource container for Azure resources (VMs, storage, databases). A subscription is associated with a tenant (one tenant), but a tenant can contain many subscriptions and management groups. In short: tenant = identity; subscription = resources and billing.

What an Entra ID tenant is used for (practical overview)

• Identity and authentication
• Manage user accounts, passwords, multifactor authentication (MFA), single sign-on (SSO), and passwordless sign-in across Microsoft and third-party apps.
• App registration and authorization
• Register applications, create service principals, and issue tokens for apps and APIs. This is how applications are granted permissions and obtain tokens to call Microsoft Graph or Azure management APIs.
• Access control
• Assign Azure RBAC and directory (Entra) roles to users, groups, and service principals to govern who can access resources and what actions they can perform.
• External identities and collaboration
• Invite partner users (B2B), provide customer identity flows (B2C), or support multi-tenant SaaS applications that let users from other Entra tenants sign in.
• Governance and compliance
• Attach subscriptions to the tenant’s management groups, apply policies and compliance controls across your organization, and centralize identity governance (for example, Conditional Access and identity lifecycle controls).

Trends and the bigger picture

• Branding: Azure Active Directory has been rebranded into Microsoft Entra ID (part of the Entra family). The rename doesn’t change the underlying tenant semantics, but highlights identity as a broader product family.
• Identity-first Zero Trust: Entra ID is increasingly the policy decision point for Zero Trust — evaluating risk signals, applying Conditional Access and enforcing least privilege.
• SaaS multi-tenant patterns: Microsoft has published more guidance and reference architectures for secure multi-tenant identity and tenant-scoped configuration.

Common challenges and best practices

• Tenant sprawl and governance
  • Problem: unmanaged extra tenants make centralized governance hard.
    • Best practice: maintain a clear subscription-to-tenant mapping, use management groups and policies, and minimize unnecessary tenants.
• Secure app credentials
  • Problem: long-lived client secrets leaking leads to compromise.
    • Best practice: prefer managed identities and certificates over client secrets in production, rotate credentials, and minimize permissions.
• Problem: multi-tenant app design affects consent, provisioning, and data isolation.
  • Best practice: decide early between single-tenant vs multi-tenant approach and design authentication/authorization flows and provisioning patterns accordingly.
• Principle of least privilege
  • Assign roles with minimal necessary permissions and use group-based or role-based assignments rather than granting broad directory admin roles.

How to find your tenant ID

• Azure/Entra admin center: Microsoft Entra (or Azure Active Directory) > Properties (or Overview) shows the Tenant ID (GUID).
• Azure CLI:
• az account show –query tenantId -o tsv
• PowerShell (Az module):
• Get-AzTenant | Select-Object TenantId, Domain
  These values are used in code and configuration (for example, building token endpoints or constructing credentials).

When to create a new tenant

• You typically create a new tenant for a distinct organization or when you need a fully isolated identity boundary (separate security/policy scopes, compliance reasons, or entirely separate administrative domains). Avoid creating tenants just to work around permissions or billing; in many cases management groups, subscriptions, and RBAC can provide the needed separation.