Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article outlines various business scenarios where customers might need to customize specific properties of out-of-the-box Dataverse columns in Microsoft Sustainability Manager to meet their organizational requirements. These scenarios highlight the importance of balancing customization needs with maintaining the integrity and functionality of the solution.
This article focuses on the customization of the following properties:
Note
When you enable additional settings that allow customers to modify a Dataverse column, they can also adjust other properties, such as Searchable, Minimum and maximum values (integer columns), and Precision (decimal columns), and Length (text columns).
These properties don't affect the built-in solution logic, but they provide flexibility for customer-specific configuration.
Business scenarios
Enhance user experience through field renaming
Organizational need: Customers might want Microsoft Sustainability Manager to reflect internal terminology to improve user adoption and operational efficiency.
Description: Customers might want to update field display names to match internal language. For example, a customer might rename "Employee ID" to "Employee Number" to help users understand fields faster, reducing training effort and data entry errors. This change updates labels shown in the UI (forms and views) while preserving standardized labels used for reporting and regulatory purposes.
Impact analysis: Renaming a field affects only the display name shown on forms and views. It doesn't change the underlying schema (column name) or the labels used in out-of-the-box reporting.
Ensure data integrity by adjusting required fields
Organizational need: To maintain data accuracy and support business processes, customers might need the ability to update the required status of fields.
Description: Customers might need to make certain fields mandatory (for example, "Environmental Impact Score") to ensure comprehensive data capture. Marking these fields as required helps reduce missing data, supports consistent sustainability assessments, and improves the quality of compliance reporting. This customization supports data integrity without disrupting the standard solution's required fields.
Impact analysis:
Customers can update a field�s Required Level, except for fields that the default solution marks as required. This update helps ensure critical fields always contain data and protects the integrity of built-in logic.
Keeping these fields mandatory helps ensure dependent processes continue to run reliably and data remains consistent.
Setting a field to "Business Required" enforces required entry in the UI only. To enforce required validation across all entry points (for example, data import), configure a Business Rule with Entity scope.
Secure sensitive data with column-level security
Organizational need: Customers might need to protect sensitive data while allowing for granular access control.
Description: To comply with data privacy regulations and internal security policies, customers might need to use column-level security for sensitive fields (for example, "Annual Emission Data" and "Employee Health Records"). This security setting enables field-level access control so that only authorized users can view or edit protected data.
Impact analysis:
Column-level security is disabled by default for out-of-the-box fields. By enabling customization, customers can configure it for specific Dataverse columns.
This configuration supports granular permissions while protecting sensitive data.
If you enable column-level security on certain required fields that Calculation Jobs use, add the built-in Service Principal (Sustainability Service Application) to the column security profile. This rule includes fields such as Approval Status, Quantity, and Quantity Unit, which are involved in microservices execution.
Optimize system performance through selective auditing
Organizational need: To enhance performance and reduce costs, you might need the ability to manage audit history selectively.
Description: You might want to disable auditing for high-churn fields (for example, "Temporary Emissions Data") that generate large volumes of audit logs. Reducing unnecessary auditing can improve system performance and lower storage consumption, while still allowing auditing to remain enabled for critical fields.
Impact analysis: By default, field-level auditing tracks changes made to specific fields within Dataverse tables and supports compliance, security, and data governance.
Benefits:
If you disable field-level audit history where appropriate, you can get these benefits:
Improved performance: Audit fewer changes for high-churn fields to improve overall system performance.
Reduced storage costs: Reduce audit log volume and associated storage consumption.
Simplified data management: Focus audit history on critical fields so it�s easier to review and analyze changes.
Enhanced privacy and compliance: Avoid auditing sensitive or personal fields when auditing isn�t required.
Focused auditing: Align auditing with business and regulatory needs so only important changes are tracked.
Meet specific project requirements by customizing field properties
Organizational need: Customers might need to adopt Microsoft Sustainability Manager to support diverse project requirements.
Description: Customers might need the flexibility to adjust certain field properties to meet project-specific needs, such as "Maximum Value for Carbon Footprint" or "Precision for Energy Consumption". These updates help ensure accurate data capture and reporting while aligning the solution to different sustainability initiatives.
Impact analysis: If customers make unmanaged configuration changes in a development environment and then promote them as a managed solution, product updates in higher environments can overwrite or conflict with those configuration changes.
Mitigation:
To mitigate this risk, customers should:
Use a well-defined Application Lifecycle Management (ALM) process to reduce the risk of product updates overwriting custom configurations:
- Apply product updates in a lower environment first (where the unmanaged solution layer is on top).
- Export the latest managed solution from the lower environment.
- After product updates are applied in higher environments, import the updated managed solution.
By following this approach, customers can reduce the risk of product updates unintentionally overwriting critical configurations.
Best practices for customization
Use the following best practices to help ensure successful customization while maintaining system integrity:
Test all customizations and configurations that you apply to out-of-the-box tables and fields. Confirm that built-in functionality, such as validations, imports, calculation profile jobs, and related processes, continues to run without errors.
If problems occur after updates or configuration changes, compare behavior against the default Microsoft Sustainability Manager settings to determine whether the cause is customization-related. This approach is critical to maintaining the integrity and functionality of the system.
Follow a structured validation approach as part of your ALM process to reduce regressions and protect solution integrity.