Please enable JavaScript.
Coggle requires JavaScript to display documents.
PL600: Architect A Solution - Coggle Diagram
PL600: Architect A Solution
Design the Security Model
Complex Scenarios
Data design
ERD to match
Think about UX
Business Unit Structure
Requirements for restricting data
Impact on performance
Not a match to org structure
Restrictions from governance
Keep it as simple as possible
Security Roles
Role vs positioning in BU structure
Minimum role to log in
Additional rights due to positioning & teams
Keep it simple
1 role or many
Define Log on vs Additional
Positional & Heiracrhical security
Hierarchy depth
Max 4 relaistically
Manager (uses SysUser links)
Positional - augment managerial
Column Security
Default no rights
Limit due to complexity in design
Maintenance
Only useful when using Client & the calls
AAD Groups
Conditional Access
Limit access to environments
Environment Roles
Resource Permissions
Can have teams/roles established in Dataverse
Global/Service Accounts
Global - Full Access
PP Admin/D365 Admin
Can do mostly everything in PP
Delegated Admin
DLP
Can Apply to all environments or some
Exceptions for certain environemtns
Prevents sharing of data between business/public
Establish Default then add exceptions
Check enabling does not break existing
Consider Sharing Row scenarios
Augment existing, but can lead to problems
Access Vs Owner
Owner
Owns Rows
Upto 1000 per user
Static Membership
Access Team
Dynamic
Access Templates
Over 1000 teams per user
POA impact
Design the Data Model
Tables and Columns
Useability vs data replication
Reference & Configuration Data
Choice
Global vs local
Can you change outside of release window
Configurable using related table
Choice vs Lookups
Third Normal Form
Dont over do it - Usability vs repetition
Ownership
Org or Team/User
If in doubt, Team/User
Custom Activities
Pros
Appears on Timeline
Roll up
Link to all ofther enabled tables
Cons
No seperate Security
Alternative Keys
Defines secondary index of data
Can be used to prevent dupes
Have a plan
Transactional vs decision making
Do you need this data in the system or just a view
Know what the end goal is
What do the senior
management want to see
Today vs 6 Months vs 2 years
AI/CI usage?
Relationships
& Behaviours
1:N
Can define security on the N
No view on N to see all 1
N:N
Security defined by "parent"
Need to define manually to add extra columns about relationship
Behaviours
Parental
Referential
Referential, Restrict Delete
Custom
Common Data Model
Derived common tables & columns across applications
Contains Metadata about the data structures
Relationships
Hierarchies
Open Source for a lot of systems on GitHub
Industry specific ones are available
Mission to drive interoperability of data
Choose where to store data
DataVerse for Transactional
Data Lake for Reporting / Feeds from other systems
Connectors for leaving it where it is
Balance disparate priorities
Lots of different stakeholders means juggling between all of them to make balance that fits the solution
Security
BI
Existing Systems
User Experience
CI
Design Integrations
Collaboration Integration
Teams
Data outside of Environment
List of records
Single Record
SharePoint
Outlook
Groups
One Note
OneDrive
D365 Integration
Security
Data Maps
Push vs Pull
Methods
Power App
Power BI
Virtual Entities
MVP
Phased integrations
Priorisation
Golden Source
Reference
Dual write
Real time vs Batch
Internal Systems Integration
Security
Patterns available
Batch vs real time
Do you need it?
Replace with connector/Virtual Table?
Third-party integration
Data residency
Security
Limit access
Restrictive users
Authentication Strategies
Application users
Data layer
OAuth
Client / Secret
App Id
Certs
O365
User log on
Business Continuity
SLA to return to business
Segregation of App
Mission Critical vs Nice to have
1 week vs 1 month
Data loss
How much is OK?
Frequency of backups
Trust in MS
Location
Integration Types
Data
Single Customer View
Reporting
Application
Single Interface, multiple source/destination
Canvas app in Model
Data Integration
Multiple apps are part of process
Case to Dev Ops
Use Azure
Closest to Data
Inbound
Use to protect D365 API
Flow & Logic Apps
Functions used to augment business logic
rather than plugins
API Limits apply
Execute Multiple of batch requests
Mostly use push, Pull for on demand data retrieval
Outbound
Flow for simple
Event Hub for multiple subscribers
Service Bus
Inbound/Outbound
Protect from Peaks
Distribute
Decouple Apps
Lead Design Process
Topology
High Level Solution Designs
Interactions with 3rd Parties
Network / Security zones
Customisations
Use of OOTB D365 vs Appsrouce vs Custom
Code maintenance
Extensibility
Proof Of Concepts
UX
Tech Feasibility
Stakeholder buy in
Pilots
Component reuse
Make things generic & reusable
Reduce custom, bespoke
Establish design criteria for re-use
ISV evaulation
Business
Technical
Security
Flexibility
Customisation
Data location
Licensing
Communicate Visually
Screen mockups
Process flows
Options
Customer journeys
ALM
Tools
Jira / Slack / TFS / Devops
Inter connections
Stories
Tech Stories
Functional Design
User Acceptance Criteria
Testable
Definition of Done
Ways of working
Devops Process
Environment management
Automation
Testing
Automation
Regression
Data valiadtion
Performance
Data Migration Strategy
What
Static vs dynamic
Historic
GPDR
Retention policies
Transactional
Volumes
Minimal Viable data
Alternatives
Keep old system
Migrate to Data warehouse
Delete
Partition Features
Splitting up apps
Best for user
Minimal clicks
Job requirements being at finger tips
Best for Testing
Reduced testing by 1 app
Scenarios around role based forms
Visualisation Strategy
Use of BI tools to complement data entry
Which metrics are used to drive the business
Current tools/skills
Design for Upgradeability
OOTB first
Configure vs customise vs develop
Understand what is coming
Know deprecations