Bizsoft360

Blog

  • SBD Part 1 – Using Microsoft’s Success by Design as Your Project Compass

    Purpose:
    This post serves as a reference guide for Solution Architects to structure and govern Dynamics 365 and Power Platform projects. It explains why the Success by Design (SBD) framework exists, how it works, and which deliverables to leverage during planning and implementation.

    Overview of Success by Design (SBD)

    SBD is a prescriptive, methodology-agnostic framework developed by Microsoft to guide project teams in architecting, building, and deploying solutions successfully. It draws on lessons from thousands of real-world implementations, providing a structured approach that minimizes surprises and maximizes predictability.

    Why it matters for a Solution Architect:

    • Ensures your design decisions align with Microsoft best practices and architecture principles.
    • Provides a governance model for proactive risk management, allowing early detection of technical, functional, and operational risks.
    • Enables repeatable success across projects, ensuring predictable delivery outcomes.

    Key Principles to Apply

    1. Proactive Risk Identification
      • Why: Reduces the likelihood of costly rework and project delays.
      • How:
        • Conduct regular Solution Blueprint Reviews (SBRs) and Implementation Reviews.
        • Track and categorize risks using the SBD template: Assertions, Risks, Issues, Recommendations.
      • Reference: SBD Review Outputs
    2. Governance Across Nine Architecture Pillars
      • Why: Ensures the solution is robust, secure, compliant, and maintainable.
      • How:
        • Evaluate architecture decisions against pillars: Security, Performance, Compliance, Maintainability, Integration, Data, UX, Operations, and Innovation.
        • Document architecture rationale in a Solution Blueprint.
      • Reference: Nine Pillars of Architecture
    3. Actionable Outputs for Decision Making
      • Why: Provides clarity for governance boards, sponsors, and project teams.
      • How:
        • Assertions: Capture what is working well to reinforce best practices.
        • Risks: Identify potential threats with impact assessment.
        • Issues: Highlight immediate blockers that require resolution.
        • Recommendations: Provide mitigation steps for risks or issues.
      • Reference: SBD Deliverables Overview

    Implementation Guidance for Architects

    • Use SBD outputs as a decision-support tool for workshops, architecture reviews, and project checkpoints.
    • Integrate SBD deliverables into your project documentation and governance artifacts:
      • Solution Blueprint (SBR Template) – defines architecture, interfaces, and integration points.
      • Implementation Review Checklist – tracks risks and issues during development.
      • Go-live Readiness Review (GRR) – ensures operational readiness before cutover.

    Best Practices:

    • Treat SBD as a living framework, updating risk and issue logs as the project progresses.
    • Reference SBD pillars early in design decisions to avoid architectural debt.
    • Align with FastTrack guidance when reviewing gaps or deviations.

    Key Takeaway

    For a Solution Architect, Success by Design is your project compass. It ensures your Dynamics 365 or Power Platform implementation is:

    • Predictable and resilient
    • Aligned with best practices
    • Governed through proactive risk management
    • Delivering maximum business value

    References / Resources:

    1. Microsoft FastTrack: Success by Design Overview
    2. Solution Blueprint Review (SBR) Template
    3. Implementation Review Checklist
    4. Go-live Readiness Review (GRR) Template

  • 311 Customer Relationship Management Design Pattern in Dynamics 365

    In public-sector service delivery, such as 311 systems, Dynamics 365 provides a robust platform for managing citizen requests, property issues, and business interactions. The key to a clean and scalable solution is designing relationships correctly between contacts, cases, and accounts.

    Core Principle

    Customer = Contact
    Properties and businesses provide context, not identity.

    All service requests, whether submitted by anonymous portal guests or registered residents, are associated with a person, not a property or business account.

    Entity Model

    Case

    • Customer (Contact) → Who submitted the request
    • Property (Account) → Location or asset involved
    • Business (Account, optional) → Related business or partner context
    • Origin / Channel → Portal, Phone, Email
    • Service / Category → Type of service request

    Primary Contact: Optional; typically unused unless a proxy submits on behalf of someone.

    Contact

    • Represents residents, guests, or business representatives
    • Guests:
      • IsGuest = true
      • Minimal profile data (name, email, session ID)
      • New Contact created per submission
    • Registered users:
      • Authenticated via portal
      • Linked to persistent Contact

    Account

    • Property Account: Civic address, Parcel ID, Ward, Property type
    • Business Account: Business name, license, address, category
    • Provides context for cases but is never used as Customer

    Portal & Guest Handling

    • Always create a new guest Contact for each anonymous submission
    • Avoid deduplication at creation
    • Merge guest → registered Contact only after authentication
    • Archive or deactivate old guest records to manage storage

    Agent Experience (Customer Service Workspace / Contact Center)

    • Customer: the submitter
    • Property: context/location of request
    • Business: optional related account
    • Cases drive workflows, timelines, and SLA tracking
    • Timelines on contacts are informational; case is the system of record

    Reporting & Analytics

    • Case + Property + Business fields enable:
      • Property-focused reporting
      • Ward/district trend analysis
      • Business or partner service metrics
      • Person-centric history

    This structure ensures identity, ownership, and privacy are maintained while supporting robust analytics.

    Benefits of this Pattern

    ✔ Scalable and secure for high-volume 311 operations
    ✔ Aligns with Dynamics 365 platform behavior
    ✔ Supports anonymous and registered portal users
    ✔ Ensures clean case ownership and agent workflows
    ✔ Enables property- and business-centric reporting without compromising identity

    Key Takeaway:

    In a 311 system, contacts represent people, accounts provide context, and cases are the system of record. Following this pattern ensures a secure, scalable, and Microsoft-aligned implementation for Customer Service, Contact Center, and Power Pages portals.

  • 311 Email Handling Design Pattern in Dynamics 365

    Core Principle

    • Customer = Contact
    • Properties and business accounts provide context, not identity.
    • Case is the system of record; email alone does not determine ownership.
    • Email activities may link to multiple contacts for history.
    • Case.Customer drives reply behavior and ownership.

    Incoming Email Handling

    1. Check tracking header
      • If Case exists → link email to that Case
      • If no Case exists → create a new Case
    2. Identify matching contacts by email
      • Multiple contacts (guest or registered) may share the same email
      • Link email activity to all matching contacts
      • Do not deduplicate automatically
    3. Assign Case.Customer
      • Registered user → Case.Customer = Contact
      • Guest → create a new guest Contact → Case.Customer = guest
    4. Handle unresolved recipients
      • If a To, CC, or BCC address matches multiple contacts, leave the party list unresolved
      • Only single matches are resolved to a Contact or Account
      • Agents see the unresolved address but can manually link if necessary

    Outgoing Email / Reply Handling

    • From / To fields: Show only Case.Customer (or original sender), not all linked contacts
    • Include tracking headers to associate replies with the correct Case
    • Replies from guests → create a new guest Contact if unmatched
    • Unresolved original recipients can optionally appear as text-only CC/BCC

    Portal Implications

    • Guest submissions always create new guest Contacts
    • Registered users override guest creation for authenticated sessions
    • Portal access is driven by Case.Customer, never email alone

    Reporting & Agent Experience

    • Cases provide centralized history and ownership
    • Email activity timeline includes all linked contacts for historical context
    • Agents work from Case-centric workflows, ensuring clean timelines
    • Property and business accounts provide context for analytics
    • Unresolved email addresses prevent confusing duplicate From/To lists

    Implementation Tips

    1. Use tracking headers in outgoing emails to associate replies with the correct Case
    2. Filter multiple contacts in From/To/CC/BCC fields via:
      • Server-Side Plugin (Pre-Operation on SendEmail)
      • Power Automate / Flow (intercept outgoing email)
      • Leave unresolved if multiple matches exist
    3. Automatically select Case.Customer for reply To field
    4. Maintain history by linking emails to all matching contacts (timeline only)
    5. Handle guest replies: create new guest Contact if no Case exists

    Benefits

    • Maintains identity integrity and privacy
    • Supports guest and registered submissions seamlessly
    • Handles duplicate email addresses safely
    • Prevents confusing recipient lists for agents and customers
    • Enables scalable, Microsoft-aligned operations
    • Preserves full email history while ensuring clean reply behavior

    Key Takeaway

    In 311 systems, cases own the workflow, contacts own identity, and emails are activities linked to all matching contacts. Case.Customer drives reply behavior, while unresolved recipients preserve email integrity without confusing agents. Property and business accounts provide context, ensuring a secure, scalable, and compliant Dynamics 365 solution.

  • Subject vs. Category in Dynamics 365 Customer Service—The 311 Playbook

    This article compares both options and shows when and how to use each in a 311 context—with clear pros/cons and a step‑by‑step setup plan.

    TL;DR

    • Use Subject to classify and route cases (the 311 service catalog).
    • Use Knowledge Article Categories to organize portal content (N:N associations for flexible browsing).
    • Keep them orthogonal: Subject = requests; Category = content.\ Sources: Define subjects, Create/manage subject tree, Knowledge categories

    What each thing is—and why it matters

    Subject (Subject tree)

    • A hierarchical structure to categorize Cases, Knowledge Articles, Products, and Sales Literature across Customer Engagement apps. It’s accessible in Customer Service Admin Center → Case Settings → Subjects and now ships with a modern TreeView control (search/highlight and an admin toggle to allow leaf‑only selection).\ Sources: Define subjects, Create/manage subject tree, Subject control improvements

    Knowledge Article Category (Category entity)

    Historical perspective: In 2016, community guidance (“Die, subject, die!”) criticized Subject’s limited customizability and UX, suggesting Category for broader customization. Since then, Microsoft has improved the Subject selection experience while retaining Subject as the canonical case taxonomy.\ Sources: CRMTipOfTheDay #641, Create/manage subject tree

    Pros and cons (311 perspective)

    Subject — Pros

    Subject — Cons

    Category — Pros

    • Flexible content navigation: N:N lets one article appear in multiple browse paths; great for portal UX.\ Source: Knowledge categories
    • Customizable & user‑owned: Historically praised for broader customization, dialogs/plugins, and security filtering scenarios (beyond KB).\ Source: CRMTipOfTheDay #641

    Category — Cons

    Recommended split for 311

    • Use Subject for the 311 service catalog (case classification and automation). Keep depth to 2–3 levels and enforce leaf‑only selection to maintain data quality (e.g., Public Works → Street Lighting → Lamp Out).\ Sources: Define subjects, Create/manage subject tree
    • Use Knowledge Article Categories for content (portal browsing and agent self‑help). Associate KBs to multiple categories as needed.\ Source: Knowledge categories

    Step‑by‑step setup (copy this plan)

    1) Build a lean Subject tree (service catalog)

    Keep it simple, enforce leaf‑only, and grow based on usage.

    Public Works

    └─ Street Lighting

    ├─ Lamp Out

    └─ Fixture Damaged

    └─ Roads

    ├─ Pothole

    └─ Sign Missing

    Waste & Recycling

    ├─ Missed Pickup

    └─ Bin Replacement

    Parks & Recreation

    ├─ Tree Trimming

    └─ Playground Maintenance

    Sources: Create/manage subject tree, CRMTipOfTheDay #1011 (start simple)

    2) Drive routing with Unified Routing / Work Classification

    Create a case workstream and rules mapping Subject to Queue, Skills, Priority, and SLA. Validate using Unified Routing Diagnostics.\ Sources: Unified routing overview, Work classification rulesets

    Tip: If agents create cases manually and you want auto‑routing without clicking Save & Route, use an Intake rule or trigger the routing action from a Dataverse flow.\ Source: Unified routing FAQs

    3) Organize Knowledge Articles with Categories

    Create resident‑friendly Categories and associate articles (N:N) for portal browsing.\ Source: Knowledge categories

    4) Iterate with analytics

    Use Customer Service historical analytics (case Topics dashboard) to identify surges (e.g., “LED ballast failures”) and refine Subjects or routing rules.\ Sources: Topics dashboard, Advanced topic clustering

    Heads‑up (conversations): AI topic clustering for conversations is being deprecated mid‑2025; continue to rely on case analytics for trend detection.\ Source: AI topic clustering (deprecation note)

    Example: Street Light Repair (311)

    • Case creation: Agent selects\ Subject = Public Works → Street Lighting → Lamp Out (leaf node).
    • Work Classification rule:\ If Subject = Street Lighting → Lamp Out → set\ Queue = Electrical Crews, Skill = Electrician (≥80), Priority = High, SLA = 48h.
    • Knowledge Article:\ “How to report a lamp out” associated to Categories Street Lighting and Public Safety, so residents find it from multiple paths.

    Sources: Work classification rulesets, Knowledge categories

    Pitfalls to avoid

    • Overly deep Subject trees → agent friction & poor data quality.\ Fix: Start small; enforce leaf‑only selection and grow based on usage.\ Sources: CRMTipOfTheDay #1011, Subject tree options
    • Mixing Categories into routing → inconsistent automation.\ Fix: Keep Category for knowledge, Subject for cases.\ Sources: Unified routing overview, Knowledge categories
    • Manual Save & Route requirement for agent‑created cases.\ Fix: Intake rule or Dataverse flow to trigger routing automatically.\ Source: Unified routing FAQs
    • Migrating Subjects across environments and preserving GUIDs.\ Fix: Use Configuration Migration Tool and managed solutions for safe movement.\ Source: Subject migration notes

    Frequently asked (311)

    Q: Can we use Category to classify Cases?\ A: Technically you can customize, but don’t for routing/reporting. Use Subject for case classification and Unified Routing for automation; keep Category for KB navigation.\ Sources: Unified routing overview, Knowledge categories

    Q: Can we restrict agents to only select leaf Subjects?\ A: Yes—toggle “Users can only select subjects without children” in Subject Management.\ Source: Create/manage subject tree

    References & further reading