Microsoft Dynamics 365 Inspection App -- 2

Overall Solution Approach (Dynamics Field Service)
The application will be built on Microsoft Dynamics 365 Field Service using Dataverse, model-driven app, and mobile offline profiles. Inspections will sync from an external system and be executed by users in the Field Service mobile app, with full offline support.
________________________________________
High-Level Structure (How the app hangs together)
Core hierarchy
Module
→ Inspection
→ Screen
→ Record
→ Questions
Key concepts
• Inspection is the parent and is synced from an external system
• Screens are logical groupings within a module
• Records are what users actually fill out
• Questions are dynamic and versioned
________________________________________

Record Creation Flow
1. Inspection sync happens
o External system creates:
 Inspection
 Inspection-specific lists (Child, Staff, Parent, Home)
 One Inspection Record per:
 Screen
 List item (Child/Staff/Parent/Home)
o This enforces:
 No duplicates
 Correct scope
 Correct ownership from day one
2. Inspection Record is auto-generated
o Inspection
o Screen
o Related Entity Type
o Related Entity (Child/Staff/Parent/Home)
o Assigned User (defaults to Lead)
o Record Status = Not Started
3. Users only interact with existing records
o They open records assigned to them
o Fill in questions
o Save or submit
________________________________________
Manual Record Addition (Still Allowed)
Your requirement still stands:
System should allow Lead to add more records if not synced
That becomes a controlled exception:
• Only the Lead can add a new Inspection Record
• The selectable list is limited to:
o Remaining Child / Staff / Parent / Home names
• Duplicate rule still applies:
o Inspection + Screen + Related Entity must be unique
This keeps data clean and predictable.
________________________________________
What Changes in the Data Model (Small but Important)
No new tables are needed. Just these clarifications:
• Inspection Record
o Is always created in context of an Inspection
o Never exists independently
• Creation source:
o Source = External Sync | Manual (Lead)
• Record ownership and assignment logic stays exactly the same
Everything else in the canvas model already supports this flow.
________________________________________
Why this matters (especially for offline)
• Offline users get all records upfront
• No risk of duplicate record creation while offline
• Security rules are applied immediately
• Validation and non-compliance logic stays consistent
________________________________________




Inspection Application – User Workflow Overview
Purpose
This document explains the end-to-end user workflow of the Inspection application. It is intended to help team members quickly understand how users move through the system, how records are assigned, and how question logic behaves.
________________________________________
Actors
• Lead: Primary user assigned at the Inspection level. Owns the inspection and overall progress.
• Associate: User assigned to specific Screen Records by the Lead. Can complete assigned records only.
________________________________________
Scenario 1: Happy Path (Inspection Execution)
1. Module Selection
• User selects a Module.
• System navigates to the Inspection List Page.
• User sees only inspections assigned to them.
2. Inspection List Page
• Displays all active inspections for the selected module.
• User selects an inspection.
• System navigates to the Inspection Detail Page.
3. Inspection Detail Page
• Displays inspection-level data in a two-column layout.
• User can start the inspection using a choice field (radio button or dropdown).
4. Navigate to Screen Records
• From the Inspection Detail Page, user navigates to Screen Records Page.
5. Screen Records Page
• Displays all Screen Records associated with the inspection.
• Records are grouped by Screen Name (sections).
6. Select Screen Record
• User selects a Screen Record.
• System navigates to the Record Form Page.
7. Record Form Page – Questions
• Displays questions associated with the selected Screen Record.
• Questions are derived through this relationship:
o Screen → Active Questionnaire → Questions
• Each screen can have a different active questionnaire.
8. Question Types
• Supported data types include:
o Choice / List
o Date
o Text
9. Submit Record
• User completes all required questions.
• On submission:
o Answers are stored in the Answer Table.
o Each answer is linked to the Screen Record and the Question.
10. Save Progress
• System automatically saves progress periodically.
• User can also manually save progress and return later.
11. Non-Compliance Flow
• If user selects No for a choice question:
o System opens a Non-Compliance screen.
o Additional details related to the non-compliance are captured.
12. N/A with Details
• If user selects N/A for a choice question:
o System displays an additional text field.
o User must enter supporting details.
________________________________________
Scenario 2: Screen Record Assignment
1. Assign Screen Record
• Lead can assign a Screen Record to another user.
• Assigned user becomes the Associate.
• Lead remains owner of the Inspection.
2. Access Control
• Once assigned:
o Screen Record becomes read-only for Lead.
o Screen Record becomes editable for Associate.
3. Reassignment Rules
• If Associate has not started the record:
o Lead can take the record back.
o Lead can reassign it to another user.
4. Associate Permissions
• Associate can view the Inspection details.
• Associate cannot modify any Inspection-level fields.
5. Associate Completes Record
• Associate fills and submits the assigned Screen Record.
• All steps from Scenario 1 apply at the record level.
6. Handover Back to Lead
• After submission, the record is returned to the Lead for review or further processing.
________________________________________
Scenario 3: Question Dependency Based on Inspection-Level Data
• Certain questions auto-populate based on Inspection-level fields.
• Example:
o Inspection field: Unannounced (Yes/No)
o If value meets a condition:
 Specific questions are auto-set to N/A.
 Default explanatory text is displayed in the associated text field.
________________________________________
Scenario 4: Question Dependency Within Record Form
• Some questions depend on answers to other questions in the same Screen Record.
• Based on user selection:
o Dependent questions are enabled or disabled dynamically.
________________________________________
Scenario 5: Question Dependency Based on Related Tables
• Question behavior can depend on data in other tables linked to the Inspection.
• Example:
o Director Approval Table contains a record with value "Secure De-escalation".
o System automatically:
 Sets specific questions to N/A.
 Displays default explanatory text.
________________________________________
Summary
• Inspections are owned by a Lead and executed through Screen Records.
• Screen Records can be delegated to Associates with strict role-based control.
• The system supports complex question logic driven by:
o Inspection-level data
o Other question responses
o Related table records
• Progress is saved continuously, ensuring inspections can be completed over time.