How a Texas-Based AI and Cybersecurity Services Company Streamlined Dataverse Choice Management in Dynamics 365

Introduction

Dynamics 365 implementations often evolve alongside the businesses they support.

A sales organization may initially define a finite set of values for a Choice column. Over time, however, new products are introduced, sales processes change, new commercial categories emerge, and terminology evolves.

The technical change may appear trivial:

But when the same request occurs repeatedly, a different problem emerges.

The business becomes dependent on the technical team for configuration changes that are fundamentally part of day-to-day business evolution.

For one of our clients, this pattern was becoming increasingly common. The organization is highly sales-focused and operates in an environment where business requirements continue to evolve.

The question therefore became:

Business Requirement

The client’s requirement was straightforward:

1. Select a Dynamics 365 table.
2. Select a Choice column.
3. Add a new option when the business needs one.
4. Update an existing option label when terminology changes.

The challenge was not simply performing these operations.

The challenge was performing them safely.

A typical Dynamics 365 user does not need unrestricted access to the Dataverse schema. Giving users broad customization privileges would create an entirely different governance problem.

I therefore needed to balance two competing objectives:

This led us to a more important architectural principle:

The Architectural Decision

Option 1: Replace the Choice with a Lookup

One possible solution was to replace the existing Choice column with a Lookup pointing to a new Dataverse table.

Conceptually, this would provide an excellent long-term model for highly dynamic business values.

For example:

Sales Record
    |
    +-- Category Lookup
            |
            +-- Category A
            +-- Category B
            +-- Category C
            +-- Category D

The business could then create new category records without changing metadata.

However, the problem was the existing implementation.

The Choice column was already being used across the solution.

Replacing it would potentially require:

1. Identifying all existing records containing the Choice value.
2. Creating corresponding records in the new Lookup table.
3. Migrating existing data.
4. Replacing the existing field references.
5. Updating JavaScript.
6. Reviewing plugins.
7. Reviewing Power Automate flows.
8. Reviewing business rules.
9. Reviewing integrations.
10. Updating reports and Power BI dependencies.
11. Testing existing processes.
12. Deploying the changes across environments.

In other words, a small configuration problem could turn into a substantial data-model transformation.

The Architectural Conclusion

How I Solved It

I designed a web-resource-based application inside Dynamics 365:

The application provides a simple interface through which an authorized user can:

1. Select a Dataverse table.
2. Retrieve the available Choice columns.
3. Select a Choice column.
4. Retrieve its existing options.
5. Add a new option.
6. Update an existing option.
7. Publish the affected table.
8. Generate an audit record.
9. Notify the system administrator.

From the user’s perspective, this becomes a simple business operation.

From the platform perspective, however, the application is interacting directly with Dataverse metadata.

The high-level architecture is:

Dynamics 365 User
        |
        v
Dataverse Choice Manager
        |
        +--------------------+
        |                    |
        v                    v
Dataverse Web API      Metadata Actions
        |                    |
        |          InsertOptionValue
        |          UpdateOptionValue
        |          DeleteOptionValue
        |          PublishXml
        |
        v
Dataverse Metadata
        |
        v
Choice Column Updated
        |
        +----------------------+
        |                      |
        v                      v
Custom Audit Log        System Administrator Email

Implementation Procedure

Step 1 – Dynamically Retrieve Dataverse Tables

The application begins by retrieving customizable Dataverse tables through the EntityDefinitions metadata endpoint.

Conceptually, the application queries:

and filters for customizable entities.

Instead of hardcoding table names, the application dynamically builds the table dropdown.

This means that if another supported table is introduced into the environment, the Choice Manager can discover it without requiring another code change.

The user sees the friendly display name while the application internally works with the logical name.

For example:

This separation between presentation and logical metadata is important when working with Dataverse APIs.

Step 2 – Retrieve Choice Columns Dynamically

Once the user selects a table, the application queries the table metadata and retrieves its Picklist/Choice attributes.

The application uses the Dataverse Metadata API to identify attributes of type:

This prevents users from attempting to manage unrelated column types.

The interface therefore becomes context-aware:

Select Table
      |
      v
Retrieve Metadata
      |
      v
Show Choice Columns

Again, no hardcoded field list is required.

Step 3 – Retrieve Existing Options

After the Choice column is selected, the application retrieves its existing options through the metadata API.

This allows the user to see both:

1. Option label
2. Option value

For example:

This is important when updating an option because the underlying integer value remains significant even when its label changes.

Step 4 – Add a New Choice Value

To add a new option, the application invokes the Dataverse:

The request contains information such as:

1. EntityLogicalName
2. AttributeLogicalName
3. Label
4. LanguageCode
5. Value

The application can therefore create a new Choice value without requiring the user to open the Maker Portal and manually modify the column.

Where an explicit option value is supplied, that value can also be passed to the API.

This gives the technical team greater control over how option values are introduced.

Step 5 – Update an Existing Choice Value

The second major operation is updating an existing option label.

The application first retrieves the existing options and allows the user to select one.

It then invokes:

An important design decision here was to capture the previous label before making the change.

For example:

The option value remains the same while the business-facing label changes.

The previous value is subsequently stored in the custom audit record.

Step 6 – Publish the Metadata

Changing metadata is not the end of the process.

The customization must be published before the change is fully available across the environment.

The application therefore invokes:

The logical flow becomes:

User Request
     |
     v
Metadata Change
     |
     v
PublishXml
     |
     v
Published Dataverse Metadata

This was an important part of the design because the user should not have to separately navigate to the Maker Portal simply to publish the change.

Custom Auditing and Governance

One of the more interesting challenges was auditing.

Dataverse provides auditing capabilities for data changes, but metadata configuration changes such as Choice modifications require a different approach when an organization wants a business-specific, detailed change history.

I therefore introduced a dedicated custom table:

The audit record captures information including:

1. Action
2. Action time
3. User name
4. User GUID
5. Entity display name
6. Entity logical name
7. Choice column display name
8. Choice column logical name
9. Option name
10. Option value
11. Previous label when applicable

A typical audit record can therefore answer:

This turns an otherwise difficult-to-track metadata operation into a business-readable audit trail.

Protecting the Audit Trail

Creating an audit table is only half of the solution.

If users can subsequently modify or delete the audit records, the audit trail itself cannot be considered trustworthy.

I therefore added server-side controls through a Dataverse plugin.

The plugin protects the audit table by:

Preventing deletion
A delete operation on the audit record is rejected.

Protecting critical fields
The plugin checks updates against protected audit attributes.

If a user attempts to modify fields such as:

1. Action
2. Action Time
3. Updating User
4. Entity
5. Choice Column
6. Option Name
7. Option ID
8. Previous Label

the operation is rejected.

This is important because client-side restrictions alone are not sufficient.

A user could potentially bypass JavaScript through another client, API call, import, or automation.

The plugin therefore establishes the governance boundary on the server.

The architectural pattern becomes:

Client-side UI
      |
      | Convenience / controlled experience
      v
Dataverse API
      |
      | Server-side enforcement
      v
Audit Control Plugin
      |
      v
Immutable Audit History

This is a broader lesson that applies well beyond this particular solution:

Email Notification

The next requirement was operational visibility.

An audit record sitting silently in Dataverse is useful, but administrators may not continuously monitor the audit table.

I therefore added an email notification after a successful publish.

The email contains the relevant information about the change and is associated with the corresponding audit record.

The process is:

Publish successful
       |
       v
Create Audit Record
       |
       v
Retrieve Audit Record ID
       |
       v
Create Email
       |
       v
Associate Email with Audit Record
       |
       v
Send Email

The association is particularly useful because it allows administrators to navigate from the email activity back to the exact audit record.

This required creating the appropriate relationship between the custom audit table and the Email activity rather than treating the custom table as a standard activity-enabled table.

That distinction is important in Dataverse: a custom business table does not automatically become an activity entity simply because activities are enabled in the user experience. Relationships and activity-party/regarding behavior must still align with the Dataverse activity model.

Working Within Dataverse Platform Boundaries

An important part of this solution was understanding the distinction between bypassing a platform restriction and working around a user-experience limitation using supported APIs.

I did not attempt to modify Dataverse metadata through unsupported database operations.

Instead, I used the exposed Web API and Dataverse actions, including:

combined with Metadata APIs for discovery.

This allowed us to create a business-friendly abstraction over capabilities that normally require technical configuration access.

The architecture can therefore be viewed as:

Complex Platform Capability
            |
            v
      Metadata APIs
            |
            v
   Controlled Abstraction
            |
            v
      Business User

Benefits of the Solution

4. Faster Business Adaptation — Changing the Operating Model

This changes the operating model from:

Business Request
      ↓
Developer
      ↓
Development
      ↓
Testing
      ↓
Deployment
      ↓
Business

to:

Authorized User
      ↓
Choice Manager
      ↓
Validated Metadata Change
      ↓
Publish
      ↓
Audit + Notification

Limitations and Guardrails

Exposing Dataverse metadata operations through a self-service interface introduces a different class of risk. The objective was not to give users unrestricted access to the Dataverse metadata layer, but to provide controlled self-service capabilities for a narrowly defined business requirement.

The solution was therefore designed with explicit guardrails around what users can change, who can change it, and how those changes are recorded.

End-to-End Working

The complete process can be summarized as follows:

                    ┌──────────────────────┐
                    │   Sales User         │
                    └──────────┬───────────┘
                               │
                               v
                    ┌──────────────────────┐
                    │ Dataverse Choice     │
                    │ Manager              │
                    └──────────┬───────────┘
                               │
                    Select Entity + Field
                               │
                               v
                    ┌──────────────────────┐
                    │ Metadata Web APIs    │
                    └──────────┬───────────┘
                               │
                 ┌─────────────┴─────────────┐
                 │                           │
                 v                           v
          InsertOptionValue          UpdateOptionValue
                 │                           │
                 └─────────────┬─────────────┘
                               │
                               v
                         PublishXml
                               │
                               v
                    ┌──────────────────────┐
                    │ Successful Publish   │
                    └──────────┬───────────┘
                               │
                  ┌────────────┴────────────┐
                  │                         │
                  v                         v
          Custom Audit Log            Email Notification
                  │                         │
                  └────────────┬────────────┘
                               v
                       Governance Trail

The important point is that the user experiences this as a single business process.

Behind the interface, however, multiple Dataverse capabilities are being orchestrated.

Why This Approach Works

The strongest part of this solution is not the API call itself.

The real value comes from the architectural decision behind it.

A common approach to an evolving Choice field is:

That can certainly be the right answer when the values represent a true business entity with its own attributes, lifecycle, ownership, relationships, or reporting requirements.

But not every frequently changing Choice requires a new table.

In this scenario, introducing a Lookup would have solved one problem while creating several others.

Instead, I asked a different question:

That shift in thinking led to the self-service metadata layer.

This is an important solution-design principle:

Conclusion

The requirement began as a recurring sales configuration request:

The obvious technical response would have been to continue handling the requests manually or redesign the field as a Lookup.

Neither approach was ideal.

Manual configuration created an ongoing dependency on the technical team, while replacing the Choice column would have introduced data migration, application dependency, integration, and regression risks.

Instead, I designed a controlled self-service layer around Dataverse.

By combining:

1. Dataverse Web API
2. Dataverse Metadata APIs
3. InsertOptionValue
4. UpdateOptionValue
5. DeleteOptionValue
6. PublishXml
7. A custom audit table
8. Server-side plugin controls
9. Email notification
10. A Dynamics 365 web resource interface

I transformed a recurring technical request into a governed business capability.

More importantly, the solution demonstrates that platform flexibility does not always require architectural replacement.

Sometimes the better architecture is to preserve the existing data model and build the right abstraction around it.

The result is a Dynamics 365 environment that is more responsive to business change while still maintaining technical governance and traceability.