Remove System Prefixes in SharePoint Lookup Columns

SharePoint lookup columns provide a simple way to surface related data from another list. They behave as expected until you include additional fields from the source list. At that point, SharePoint generates labels like Lookup:Column for each extra field.

The key detail is that these are not view aliases or temporary labels. SharePoint creates actual columns for each additional lookup field and assigns them names using a default naming pattern.

Once you understand that these are real columns, the solution is straightforward.

How Additional Lookup Columns Work

When you configure a lookup column, you define a relationship between two lists. The naming pattern appears only when you include additional fields from the source list.

Each selected field becomes its own column in the target list. SharePoint prefixes the column name with the lookup column name to preserve context. This is why you see names like Lookup:Column instead of just Column.

These fields behave like regular columns after creation. They appear in List Settings, can be edited, and their display names can be changed independently of the lookup relationship.

Instructions

In this demonstration, the source list contains a series of Projects with an associated Title (Project Name) and Status.

Step 1: Create the Lookup Column

The setup process is standard.

You create a lookup column in the target list, point it to a source list, and select the primary value to display.

You can optionally enable additional fields to include more data.

Once saved, SharePoint generates the dependent columns automatically. These are the fields that appear with the prefixed naming pattern.

Step 2: Locate the Generated Fields

After creating the lookup column, go to List Settings and view the Columns section. You will see the additional fields that were not manually created.

These dependent lookup fields behave like normal SharePoint columns, which is why their display names can be changed independently.

Step 3: Rename the Columns

Renaming is done directly in each field’s settings page.

Open List Settings and select a generated lookup field.

Update the Column name and save. For example, Project Name:Status can be renamed to Status or a clearer business label.

SharePoint immediately updates the display label across list views, forms, and most user-facing interfaces.

The lookup relationship remains intact because SharePoint relies on the internal field definition rather than the display name.

Internal Name vs. Display Name

Renaming only changes the display label. The internal name does not change.

A column shown as Status in the UI may still have an internal name like Lookup_x003a_Status. SharePoint continues to use internal names for integrations and backend operations.

This becomes visible in Power Automate and any tool that exposes raw field metadata. The UI may show a clean label while flows reference the original internal structure.

This mismatch is expected and unaffected by renaming.

NOTE: SharePoint does not support changing internal field names after creation. If an internal name must change, the column generally needs to be recreated.

Impact on Power Automate and APIs

The distinction between display and internal names is especially important outside SharePoint.

Power Automate, REST APIs, Microsoft Graph, and reporting tools often expose internal field names rather than display labels. A field shown as Status may still appear as Lookup_x003a_Status.

This matters when lookup columns are deleted and recreated. Even if the new column uses the same visible name, SharePoint generates a new internal field definition. Existing flows, JSON formatting, REST queries, and Power BI models can break because they reference the original identifier.

For this reason, lookup schema changes are safer early in a project, before downstream dependencies build up.

Why Some Additional Fields Are Not Available

Additional lookup fields work best with simple scalar column types such as text, number, date, currency, and yes/no values. More complex types such as multi-select choices and certain calculated fields may not always be available as additional lookup fields, depending on the field configuration and service being used. When complex data must be surfaced through lookups, a Power Automate process is often used to flatten the value into text first.

Edge Cases and Troubleshooting

Most issues with renamed lookup fields appear after setup, not during it.

A common issue is that newly created lookup fields do not immediately show dependent columns in List Settings. This is usually a caching delay and resolves with a refresh.

Another issue occurs when lookup columns are deleted and recreated. SharePoint generates entirely new dependent fields each time. Even if names match, internal identifiers change, which can break flows, JSON formatting, and Power BI reports.

In Power Automate, the UI may show the renamed column, but outputs still expose the internal field name. Checking raw output is often the only reliable way to confirm structure.

In larger lists, updates from the source list may not appear immediately in dependent fields due to indexing or rendering delays.

Finally, renaming the parent lookup column does not update dependent fields. The original prefix remains unless updated manually.

Results

After renaming dependent lookup fields, SharePoint lists become easier to read and maintain. Views, forms, and reports no longer expose strange looking column labels.

The lookup relationship remains unchanged. Data stays synchronized, filtering and sorting continue to work, and no structural changes are required.

Summary

SharePoint lookup columns are more flexible than they first appear, but additional fields introduce unwanted default naming.

Once you understand that these generated fields are real columns rather than static labels, renaming becomes a simple cleanup step.

In practice, this is less about formatting and more about removing unnecessary technical noise from everyday list structures.