Alternate keys in Dataverse: use them to enforce uniqueness

Go back to Glossary
Share:

Introduction and Overview

Alternate keys in Dataverse give you a flexible way to uniquely identify records using business-specific fields, instead of relying only on system-generated identifiers. This option is especially important for organizations that need to keep their data accurate and consistent when connecting Dataverse to external systems or moving data from older platforms. By letting you add extra unique identifiers beyond the default primary key, alternate keys make it easier to connect your data to real business concepts and simplify the process of integrating with other tools. Plus, using alternate keys helps you meet both day-to-day operational needs and compliance requirements by making sure your records stay unique in all kinds of business situations.

It’s also worth considering that alternate keys are a big help for organizations that need to follow regulations like GDPR or HIPAA, where tracking and pinpointing records is a must. Since alternate keys allow you to use familiar business data as unique identifiers, it becomes much easier to handle audits and generate reports, which can be a real advantage when you need to show compliance and keep records straight across different systems.

Understanding Alternate Keys Fundamentals

Exploring alternate keys in Dataverse can significantly benefit from the expertise of power platform consulting services. These services offer valuable insights into optimizing data connections, enhancing system integrations, and maintaining data integrity, all while ensuring compliance with industry standards. By leveraging tailored solutions and expert guidance, organizations can unlock the full potential of Power Platform to streamline their business operations.

What are alternate keys

Alternate keys are fields you define—either alone or in combination—that uniquely identify a record in a Dataverse table. Unlike the system’s primary key, which is usually a GUID, alternate keys can be based on data that actually means something to your business, like email addresses, product codes, or other important details. The real benefit here is that you can refer to records using data points people already know, making it easier to connect Dataverse to outside sources that might not use GUIDs.

For example, imagine a retail company using a product’s SKU as an alternate key, or a healthcare organization relying on a patient’s medical record number. These identifiers are already woven into daily work, so they’re instantly recognized by both your team and outside partners, making data management more practical both inside Dataverse and beyond.

Primary keys vs alternate keys

FeaturePrimary Key (GUID)Alternate Key
System-generatedYesNo (user-defined)
Business meaningNoYes (e.g., email, SKU, etc.)
RequiredAlwaysOptional
Supports compositesNoYes
Used for integrationsRarelyFrequently

Take this for example: the GUID works great for system processes and ensures no two records ever share an ID, but it isn’t something your sales team or your partners will recognize. Alternate keys fill that gap by letting you use familiar attributes like invoice numbers or employee IDs, so your systems stay robust and your users stay comfortable.

When to use alternate keys

You’ll want to use alternate keys when external systems or business processes identify records using data other than the GUID. This comes up a lot in:

  • Data integration projects where the original system uses its own identifiers
  • Migrating from legacy databases
  • Workflows that rely on natural keys like account numbers or emails
  • Preventing duplicate records with the same important business attribute

For instance, if you’re connecting Dataverse to a legacy CRM that uses customer email addresses as unique IDs, setting up the email field as an alternate key lets you sync records between both systems without worrying about GUIDs. Or in a manufacturing scenario, alternate keys based on part numbers help you keep records consistent and unique across your supply chain and inventory systems.

Technical Implementation and Creation

Creating alternate keys through Power Apps Portal

The Power Apps Portal is designed to make creating alternate keys straightforward. As an administrator, you can:

  • Go to the table you need
  • Find the Keys area
  • Define a new alternate key by picking one or more fields

The portal checks to make sure your choices are compatible and unique. Once you save, Dataverse takes care of the rest—building the necessary database indexes to enforce uniqueness and boost performance. This method works well for most everyday needs and makes managing alternate keys in Dataverse pretty simple.

Let’s say you’re managing a customer table. You can set the “Email” field as an alternate key directly in the portal. All you have to do is pick the field, make sure it’s the right type and unique, and save. The system creates the database index for you, so you can start using that alternate key for integrations and lookups right away.

Advanced creation using Solution Explorer

Solution Explorer is a more advanced option in the Power Platform, letting admins and developers set up alternate keys as part of managed or unmanaged solutions. With Solution Explorer, you can:

From vision to execution

Whether you're just starting or scaling automation, we help turn your ideas into impactful solutions.

  • Add alternate keys to tables
  • Bundle them in solution packages
  • Move configurations between different environments

This is really helpful if you’re dealing with complex deployments, need version control, or want to manage multiple environments at once. It’s especially useful for organizations that are serious about application lifecycle management.

For example, when you’re rolling out a new app to both your development and production environments, Solution Explorer makes it easy to keep alternate key configurations consistent across the board. That way, your rules for data integrity stay the same everywhere, and you can track changes or updates using systems like Azure DevOps.

Programmatic creation

If you prefer automation, you can create alternate keys programmatically using the Dataverse Web API or the SDK for .NET. Here, developers specify the table and fields to include as the alternate key. This is essential when you want to automate processes, configure in bulk, or fit alternate key creation into custom deployment pipelines. Using the API or SDK, you can check field types, handle errors, and create keys dynamically as part of deploying or upgrading solutions.

For example, a developer might write a script to set up alternate keys across multiple tables as part of an automated deployment. The script can check for existing keys, handle any issues if fields don’t meet requirements, and keep logs for auditing. This approach is especially helpful in larger organizations using infrastructure as code to manage Dataverse at scale.

Supported field types and constraints

Not all field types can be used for alternate keys. Supported types include:

  • Single line of text
  • Whole number
  • Decimal number

Constraints to keep in mind:

  • Each field must have unique and non-nullable values
  • Maximum of 10 alternate keys per table
  • Composite key can include up to 5 fields
  • Total size of a key can’t go over 900 bytes
  • Lookup, choice, and image fields are not supported

For example, if you want to create a composite alternate key using “FirstName,” “LastName,” and “DateOfBirth,” you have to make sure all three are allowed types and their total size fits within the 900-byte limit. If any field is nullable or not unique, Dataverse won’t let you create the key, which helps keep your data accurate and your system running smoothly.

Integration and Usage Scenarios

External system integration

Alternate keys are a must-have when you’re integrating Dataverse with external systems like ERP, CRM, or custom databases. These external platforms often use their own business-specific identifiers that might not match up with Dataverse GUIDs. By setting up alternate keys to match those external IDs, you can make sure data flows smoothly between systems, stays in sync, and remains accurate. This setup makes mapping records much more intuitive and keeps integration logic from getting too complicated.

For example, let’s say your finance team uses an outside accounting system that tracks invoices by “InvoiceNumber.” By using “InvoiceNumber” as an alternate key in Dataverse, integration tools like Azure Logic Apps or custom connectors can match, update, or pull records directly—no need for extra transformation steps. This keeps integrations simple and reduces the risk of mismatched data.

Power Automate implementation

Power Automate flows can take advantage of alternate keys to find and work with records in Dataverse. Instead of relying on GUIDs, flows can use business-specific fields you’ve set up as alternate keys. This makes your automation logic a lot cleaner, especially when you’re dealing with outside data sources or user input that doesn’t give you system-generated IDs. Using alternate keys in Power Automate makes things easier to maintain and helps avoid errors from referencing the wrong records.

For example, if you have a flow that handles support tickets coming in by email, you can use the sender’s email address—set as an alternate key—to look up the matching customer in Dataverse. This way, you don’t have to keep a separate mapping of emails to GUIDs, which cuts down on complexity and mistakes in your automation.

API usage examples

Both the Dataverse Web API and SDK for .NET let developers work with alternate keys for create, update, upsert, and retrieve actions. Instead of a GUID, you can use an alternate key as the identifier in your API calls. For example, a Web API request can specify the alternate key value in the URI, which is perfect for integration scenarios where outside systems provide business IDs instead of GUIDs. Microsoft’s documentation includes code samples and syntax you can adapt for different programming environments.

Example API call:

GET [Organization URI]/api/data/v9.1/accounts(accountnumber='A12345')

This lets you pull an account record using “accountnumber” as the alternate key, rather than the system’s internal GUID. This is especially helpful for RESTful integrations where mobile apps or external applications interact with Dataverse using IDs that make sense for the business.

Data migration scenarios

When migrating data, it’s important to keep existing business identifiers intact as you move information into Dataverse. Alternate keys make this possible by letting you reference and validate records using fields from legacy systems. This ensures your migrated data stays consistent and that future integrations or updates can still use the familiar business keys.

For instance, if you’re moving customer records from a SQL Server database to Dataverse, you could use the old “CustomerID” as an alternate key. This helps map records accurately during migration and keeps ongoing syncs between systems reliable. Plus, after migration, you can still cross-check records using the original identifiers.

Performance and Optimization

Database indexing benefits

When you set up an alternate key, Dataverse automatically builds a database index on those fields. This index keeps records unique and makes lookups much faster. As a result, any queries that filter or join on alternate key fields see better performance—especially in big tables or high-traffic environments. Indexing also helps prevent duplicate data and makes it easier to enforce business rules.

For example, a sales team dealing with millions of orders can use alternate keys on order numbers to quickly find or update records. This keeps things running smoothly even as data grows. The indexing approach here is similar to what you’d find in enterprise databases like Microsoft SQL Server or Oracle.

Query optimization

Alternate keys help optimize queries by letting Dataverse quickly find records based on business-specific attributes. Developers and analysts can write queries that use these keys for faster results. This is particularly important in automations, integrations, and reporting where speed really matters.

For example, if your Power BI reports summarize sales by “OrderID” (an alternate key), the underlying index will help your dashboards refresh faster and stay responsive. That’s a big plus for organizations that need up-to-the-minute analytics or support lots of users at once.

Bulk operations

Bulk data processing—like imports or updates—gets a boost from alternate keys. You can use them to match incoming data to existing records, which streamlines operations and cuts down on mismatches. This is handy for ongoing data syncs, scheduled imports, or big batch updates where performance and accuracy are top priorities.

For example, a healthcare organization importing lab results from various labs can use patient medical record numbers (alternate keys) to match and update records quickly, making sure results are linked to the right patient and reducing manual work.

Performance monitoring

It’s important to keep an eye on how alternate keys affect database performance. While indexes usually speed up lookups, too many or poorly designed alternate keys can use up resources and slow things down. Admins should regularly check performance metrics, index usage, and table sizes to make sure everything is running smoothly and catch any issues early.

You can use built-in tools in the Power Platform Admin Center or third-party monitoring solutions to track how indexes are being used and spot potential slowdowns. Regular performance reviews are a smart move as your data and business needs keep changing.

Constraints and Limitations

Field type restrictions

Alternate keys can only use certain field types:

  • Single line of text
  • Whole numbers
  • Decimal numbers

Fields like lookups, choices, multi-select options, or images aren’t allowed. Also, any field used as an alternate key has to be required (not nullable) and must not allow duplicates. These rules help keep indexes efficient and your data accurate.

For example, if you try to use a lookup field that points to another table as an alternate key, you’ll get an error. That’s because those fields can make it harder to keep uniqueness, especially if relationships change or get deleted.

Size and quantity limits

  • Up to 10 alternate keys per table
  • Each composite key can have up to 5 fields
  • Total size of all key fields together can’t go over 900 bytes

If you try to go over these limits, Dataverse will stop you and ask you to review your key setup.

For example, if you try to define eleven alternate keys for a single table, the system will block it and prompt you to reconsider which fields really need to be alternate keys. This helps you focus on what’s most important for your business.

Special character handling

Fields used in alternate keys may have limits on special characters or Unicode symbols. Unsupported characters can cause errors when creating keys or working with data. It’s best to stick with simple, alphanumeric values for alternate keys to avoid problems with indexing or integrating with other systems.

For example, using commas, semicolons, or emojis in alternate key fields could cause syncing or API queries to fail. To avoid these headaches, organizations should set up data entry standards and validation rules to keep alternate key fields clean and compatible.

Security considerations

Alternate keys fall under Dataverse’s security setup, including field-level security and role-based access. Sensitive fields used as alternate keys should be protected based on your organization’s policies. Admins need to make sure users and integrations have the right permissions to access and update alternate key values, without exposing private information.

For example, if a social security number is used as an alternate key in a government app, field-level security should ensure only authorized staff can see or change it. Audit logs should also be turned on to track access and changes, which helps with compliance and internal controls.

Troubleshooting and Best Practices

Common implementation issues

Some common issues with alternate keys include:

Automate tasks that slow you down

Free up your team’s time and focus on strategic work with digital and robotic automation.

  • Trying to use fields that aren’t unique or are nullable
  • Going over the size or field count limits
  • Picking unsupported field types
  • Duplicate data in a field you want to use as an alternate key
  • Integration problems if external systems send values that don’t match your key constraints

For example, if a company tries to create an alternate key on a “PhoneNumber” field that has duplicates or blank entries, the system will reject it. The company would need to clean up the data first to make sure every value is unique and filled in.

Best practice recommendations

  • Choose alternate keys based on fields that are stable, important to your business, and unlikely to change
  • Avoid fields that could have duplicates or missing data
  • Only set up as many alternate keys and fields per key as you really need for your operations
  • Review key definitions regularly and update them as your business evolves
  • Document why each alternate key exists, what it’s used for, where the data comes from, and any related integrations

This documentation helps with audits, troubleshooting, and training new team members.

Maintenance and monitoring

Keeping alternate keys effective means:

  • Regularly checking for performance issues
  • Watching for duplicate data
  • Making sure key fields stay unique and filled in
  • Scheduling audits to catch problems early

Organizations should set up regular data quality checks, using both automated tools and manual reviews, to spot any issues that could affect how alternate keys work. Being proactive here helps avoid disruptions and supports good data governance in the long run.

Performance troubleshooting

If you run into performance issues:

  • Review how many and what kind of alternate keys you have
  • Check for large indexes
  • Review your database metrics
  • Remove any unused or unnecessary alternate keys

Don’t hesitate to work with database admins or Dataverse experts to track down and fix any bottlenecks related to your alternate key setup.

For example, if a high-traffic table is running slow, reviewing the alternate key configuration might show that outdated or overly complex keys are using up resources. By cleaning up and simplifying your key setup, you can get performance back on track and keep scaling as your data grows.

Frequently Asked Questions

What is the difference between a primary key and an alternate key in Dataverse?

A primary key is a system-generated GUID that uniquely identifies each record and is always required. An alternate key is user-defined, can be based on business-specific fields, and provides an additional way to ensure uniqueness and support integrations.

How many alternate keys can I have per table in Dataverse?

You can have up to 10 alternate keys per table. Each composite alternate key can include up to 5 fields, and the total size must not exceed 900 bytes.

Can I use lookup or choice fields as alternate keys?

No, only single line of text, whole number, and decimal number fields are supported for alternate keys. Lookup, choice, multi-select, and image fields are not allowed.

Why would I use alternate keys for integrations?

Alternate keys allow external systems to identify records using business-relevant data, such as email addresses or product codes, making integrations more intuitive and reducing the need for mapping GUIDs.

What should I do if Dataverse rejects my alternate key creation?

Check that all fields are unique, non-nullable, supported types, and that you’re not exceeding the size or number limits. Clean up any duplicate or missing data before trying again.

Share:
Go back to Glossary

Table of Contents

Need expert guidance on Power Platform solutions? Contact us today for professional consulting
Author
Power Platform Consultant | Business Process Automation Expert
Microsoft Certified Power Platform Consultant and Solution Architect with 4+ years of experience leveraging Power Platform, Microsoft 365, and Azure to continuously discover automation opportunities and re-imagine processes.