Metadata-Driven Application Architecture & PowerApps

Summary: This post is the completion of the one I wrote on using Atomic Design in the architecture of web based forms, specifically Power Platform Canvas applications. The idea is to create a metadata structure that defines business objects in a data repo that loads upon application initialization. One of the benefits of this is for scenarios where you have multiple buiness definitions for the same process but not all of them clearly outlined as of yet. Instead of blocking the project, you can simply lead with what you have and move immediately forward. Stated another way, it decouples your engineering effort from the business rules while allowing the rules to evolve over time without furhter build time. Low touch, high value.

Overview of the Pattern

The Metadata-Driven Application pattern involves storing business rules, form configurations, and UI behaviors externally (e.g., in a database like Dataverse). The application dynamically reads these configurations at runtime (on App Start or when a Screen becomes Visible) and renders the UI accordingly. To use this, you would need to have an application that has defined form fields and possibly a structure like some sort of domain differentiation like department (govt) or distribution channel (manufacturing and supply chain). Then upon load, the app fetches the rules, based on the action or actor performing the action, the specific rules apply and the UI renders to serve that specific purpose.

This approach allows for:

Flexibility: Easily update business rules without changing the application code.
Scalability: Accommodate new customers or changing requirements by updating data entries.
Maintainability: Centralize business logic, making it easier to manage and audit.

Implementation Steps in Power Apps

Define Business Rules in Dataverse:

Create Entities/Tables: Set up tables in Dataverse to store business rules. For example:
- Customers: List of customers with unique identifiers.
- FieldRequirements: Mapping of required fields per customer.
- ValidationRules: Any specific validation logic per field/customer.

Sample Structure:

CustomerID	FieldName	IsRequired	ValidationRule
1	ProductName	Yes	NotEmpty
1	ExpirationDate	Yes	FutureDate
2	ProductName	Yes	NotEmpty
2	BatchNumber	No	Alphanumeric

Load Business Rules on App Start:
- OnStart Property: Use the OnStart property of the app to load the rules into collections or variables.
```
ClearCollect(
  colFieldRequirements,
  Filter(
    FieldRequirements,
    CustomerID = SelectedCustomerID
  )
);
```
- Variables for Quick Access: Store commonly used rules in variables for faster access.
```
Set(
  reqFields,
  Filter(colFieldRequirements, IsRequired = true)
);
```

Dynamic UI Rendering:

Visibility Properties: Set the Visible or DisplayMode property of controls based on the loaded rules.
```
// For a required field
If(
  LookUp(reqFields, FieldName = "ProductName"),
  true,
  false
)
```

Conditional Formatting: Use conditional logic to highlight required fields or enforce validation.

// Display a red asterisk for required fields
If(
  LookUp(reqFields, FieldName = ThisItem.FieldName),
  "✱",
  ""
)

Validation Logic:

OnChange or OnSubmit Events: Implement validation checks based on the rules.

If(
  LookUp(reqFields, FieldName = "ExpirationDate") && DateValue(ExpirationDateInput.Text) <= Today(),
  Notify("Expiration Date must be a future date.", NotificationType.Error),
  SubmitForm(ProductForm)
)

Responsive to Screen Visibility:
- OnVisible Property: In cases where screens may change based on navigation, use the OnVisible property to refresh or adjust rules.
```
OnVisible = Collect(
  colCurrentScreenRules,
  Filter(
    ScreenRules,
    ScreenName = "ProductDetails" && CustomerID = SelectedCustomerID
  )
)
```
Dynamic Form Generation (Advanced):
- Use Galleries for Fields: Instead of static forms, use a gallery to iterate over the fields that need to be displayed.
  - Items Property of Gallery:
```
Filter(
  colFieldDefinitions,
  CustomerID = SelectedCustomerID
)
```
  - Inside the Gallery: Use controls like TextInput or Dropdown, and bind their properties to the fields.
Caching and Performance Optimization:
- Data Caching: Store the business rules in collections to minimize calls to Dataverse.
- Delegation Considerations: Ensure that your filters and data operations are delegable to handle large datasets efficiently.

Benefits of This Pattern

Adaptability: Easily adapt to new customer requirements by updating the Dataverse tables without modifying the app’s codebase.
Consistency: Centralized rules ensure all users have a consistent experience based on their customer profiles.
Maintainability: Business analysts or non-developers can manage the rules directly in Dataverse.

Considerations

Complexity:
- Initial Setup: Designing the metadata structure requires careful planning.
- Debugging: Issues may be harder to trace due to the dynamic nature of the UI.
Performance:
- Data Loading: Loading large sets of rules can impact performance. Optimize by loading only what’s necessary.
- Caching Strategies: Implement caching where appropriate to improve responsiveness.
- Scope: If not cross screen(s) in Power Apps, prefer context variables over globals to reduce memory consumption.
Security:
- Data Access Control: Ensure that users have appropriate permissions to read the business rules but not necessarily modify them.
- Validation: Even though the UI enforces rules, always validate on the backend (Dataverse or any connected data sources) to prevent malicious data entry.
User Experience:
- Dynamic Changes: Be cautious with controls appearing or disappearing, as it may confuse users. Use placeholders or disable controls instead of hiding them, when appropriate.
Testing:
- Comprehensive Testing: Test all combinations of customer rules to ensure the UI behaves as expected.
- Fallback Mechanisms: Implement default behaviors when rules are missing or data fails to load.

Example Scenario

Customer-Specific Requirements:
- Customer A requires fields: Product Name, Expiration Date, and Batch Number.
- Customer B requires fields: Product Name and Quantity.
Implementation:
- Dataverse Tables: FieldRequirements table maps required fields to each customer.
- App Start: When the app starts, it loads the required fields for the selected customer into colFieldRequirements.
- UI Rendering: The form displays only the fields that are required for the selected customer.
- Validation: On form submission, the app checks that all displayed required fields are filled out.

Advanced Extensions

Role-Based Rules: Extend the pattern to include user roles, so the UI adapts based on both customer and user permissions.
Rule Prioritization: Implement logic to handle conflicting rules or prioritize certain rules over others.
Localization: Store language-specific labels and messages in Dataverse to support multiple languages dynamically.

Conclusion

By adopting the Metadata-Driven Application pattern in Power Apps, you create a flexible and maintainable solution that adapts to varying business rules and customer requirements. Storing business rules in Dataverse allows non-developers to manage them, while the app dynamically renders the UI based on these rules at runtime.

This approach enhances the scalability of your application, reduces the need for frequent code changes, and improves overall efficiency in managing complex business processes.