I attended CollabDays Bremen last weekend. Session led by Stalin Ponnusamy, MVP provided a comprehensive and practical deep dive into Power Platform governance, breaking down the layered security model that organizations must understand to protect sensitive data in a world where AI tools make development faster and easier than ever. Stalin emphasized that while anyone can now build apps and flows, security must be intentionally architected, not left for AI or platform defaults to decide.
1. Overview of the Session
The session focused on the foundations and advanced layers of Power Platform governance, especially security at scale. Stalin emphasized that while AI‑driven tools like Copilot and ChatGPT speed up development, security must always be an intentional architectural decision, not an afterthought.
He framed the entire discussion around the importance of controlling data access, safeguarding sensitive information, and structuring environments so organizations can innovate without compromising security or compliance.
2. Key Themes Covered
2.1 Security as a Multi‑Layered Architecture
Stalin used practical analogies to simplify complex Dataverse security concepts:
- Tenant = Gated community
- Environment = Individual buildings
- Security roles = Keys or access cards
- Business units = Floors of a building
- Field-level security = Lockers inside the room
- DLP = Rules preventing items from being carried out of the building
These analogies were used to explain how Dataverse enforces security at multiple levels—from broad tenant authentication down to individual fields.
3. Observations on Common Security Gaps
3.1 UI-Level Security Is Not Real Security
Stalin repeatedly emphasized that hiding data on forms or views is not true security.
Because AI tools can surface underlying data, only Dataverse-level restrictions protect the organization.
He described real-world failures where projects relied on JavaScript or form logic to hide data. When AI or integrations queried the data, hidden fields became visible, exposing sensitive content.
4. Business Units, Row-Level Security & Access Teams
4.1 The Session Perspective
Stalin highlighted business units, access teams, and field‑level security as highly underused, especially in Power Platform-only projects.
4.2 Your Added Perspective
From your professional viewpoint:
- Many Power Platform projects are small or departmental
→ They often do not require business units or row-level security due to their scale. - But in Dynamics 365 projects, these structures are essential
→ D365 heavily relies on business units, deep role-based security, and data partitioning as native architectural principles.
Because of this, every Power Platform professional should understand the difference between:
- Restricting data at the Dataverse level (table, row, field)
- Hiding data at the UI level (form or view)
Misunderstanding this difference leads to governance failures and vulnerabilities when solutions scale or integrate with AI.
5. Access Team Models & Sharing Approaches
5.1 Manual Sharing
- Suitable for small teams and individual records
- Not scalable
- Can create complex, unmanageable sharing chains
5.2 Access Team Templates
- Better for scalable enterprise environments
- Allow programmatic, rule-based access assignment
- Example: Approval scenarios, temporary collaborators, project teams
Real customer scenarios were shared—e.g., a pharmaceutical deal management project—where complex security transitions were managed using owner teams + access teams, with zero custom code.
6. Environment-Level Governance
Key components highlighted:
- Azure AD Security Groups controlling who can access each environment
- DLP Policies to prevent unauthorized data movement
- Connector restrictions (e.g., blocking Facebook, Twitter, external APIs)
- IP-based network rules for sensitive integrations (SAP, SQL, etc.)
- Auditing & logs for compliance, troubleshooting, and Microsoft support
A recurring issue noted:
Most environments are accidentally configured with “None” security group, allowing everyone access.
This is a significant governance risk.
7. Compliance Considerations
Stalin tied governance to compliance standards such as:
- GDPR
- HIPAA
- SOX
- Internal auditing & regulatory frameworks
Non-compliance can lead to major financial impact, especially in sensitive industries like healthcare and finance.
8. Conclusion & Recommendations
8.1 Summary
The session reinforced that Power Platform security is not “nice to have”—it is a foundational discipline. With AI surfacing data more freely, proper Dataverse security is no longer optional.
8.2 Your Professional Viewpoint
- For small Power Platform solutions, deep security layering may not be necessary.
- For Dynamics 365 or enterprise-scale Power Platform, row-level security, business units, DLP, and environment-level controls are mandatory.
All Power Platform personnel should be trained to understand:
- How Dataverse enforces security
- Why UI hiding is not real protection
- When to apply more advanced layers (BU, access teams, field security)
8.3 Recommendations for Internal Governance
- Standardize environment security group usage
- Establish DLP templates for all customer projects
- Require Dataverse-level permission definitions in project architecture documents
- Train all consultants on business unit/row-level security differences
- Include AI/Copilot data exposure in solution design reviews