Auto-fill the SharePoint Title Column: What Actually Works

SharePoint's built-in Title column often feels redundant. Your list may already have fields such as Facility, Request Type and Week Ending, and the useful label is a combination of those values.

The important distinction is whether you want to:

1. Display a calculated label without changing stored data.
2. Create a separate calculated column.
3. Populate the actual Title while the user saves a Power Apps form.
4. Update the stored Title after saving with Power Automate.

Those approaches have different behaviour in views, search, APIs and integrations. There is no honest one-size-fits-all fix.

Fact-checked against Microsoft Learn and Microsoft Support on 7 August 2026.

The short answer

• Use column formatting when the value only needs to look calculated in a view.
• Use a separate calculated column when you want SharePoint to maintain a reusable same-row calculation.
• Use a Power Apps custom form when the Title must be stored during the user's save operation.
• Use Power Automate when the stored Title can be filled after creation and you can operate the extra run, write and failure gap.

Do not confuse a formatted display with stored data. Microsoft explicitly says column formatting changes how a field is displayed; it does not change the data in the list item.

Example used in this guide

Imagine a list with:

• Facility — single line of text;
• Week Ending — date; and
• Title — the built-in SharePoint text column.

The desired label is:

Bristol - 2026-08-07

Use your own business fields, but keep the first test simple. Person, lookup, managed-metadata and multi-select fields return more complex values and need different handling.

Option 1: display a calculated label with JSON

Column formatting is the lightest approach. It can reference other fields in the same item using expressions such as [$FieldName].

Apply formatting to the Title column—or to a separate display column—and render the label from Facility and Week Ending.

Example JSON

This example assumes the internal names are Facility and Week_x0020_Ending:

{
  "$schema": "https://developer.microsoft.com/json-schemas/sp/v2/column-formatting.schema.json",
  "elmType": "span",
  "txtContent": "=[$Facility] + ' - ' + [$Week_x0020_Ending.displayValue]"
}

To add it:

1. Open the list view.
2. Open the target column's menu.
3. Select Column settings > Format this column.
4. Open Advanced mode.
5. Paste the JSON and save.

The _x0020_ portion is how SharePoint commonly encodes a space in an internal column name, but never assume it. Open the column settings URL or inspect an existing formatter to get the exact internal name.

What this option does not do

The stored Title remains whatever is actually in the item. That means:

• an API or export can still return the stored Title;
• another view without the formatter may show the stored Title;
• sorting and filtering use the underlying field behaviour, not a new composite value; and
• an integration reading Title does not receive the visual label.

Use formatting when that boundary is acceptable. It is an interface improvement, not an automatic data update.

Option 2: add a separate calculated column

SharePoint calculated columns can combine values from other columns in the same row. Microsoft documents & and the TEXT function for joining text with a formatted date.

Create a calculated column called Display title whose result type is Single line of text. For the example fields, use:

=[Facility]&" - "&TEXT([Week Ending],"yyyy-mm-dd")

Depending on the regional settings of your site, SharePoint may require semicolons rather than commas as function separators. Use the formula syntax the list's calculated-column editor accepts.

Why this can be better than formatting

The calculation is a real list column. You can include it in views and use it consistently as its own field.

But it is still not the built-in Title. Any app, flow or integration that specifically reads Title will not automatically switch to Display title.

Calculated columns also have limits. Microsoft notes that they work within the same row; they cannot pull values from another list, and lookup fields are not supported in formulas. A newly generated item ID is not available to the calculation at insert time.

Choose this option when a separate computed field is honest and downstream systems can use it by name.

Option 3: populate Title in a Power Apps custom form

A customised SharePoint form can calculate Title while the user saves the item. This stores the value in the actual Title column without waiting for a separate flow run.

From the list, use Integrate > Power Apps > Customize forms. Microsoft documents that the default cards, including Title, are initially locked. Select the Title card and unlock it before changing properties.

Then set the Title data card's Update property to a formula based on the input controls. An illustrative pattern is:

Concatenate(
    Trim(DataCardValue_Facility.Text),
    " - ",
    Text(DatePicker_WeekEnding.SelectedDate, "yyyy-mm-dd")
)

Your controls will not necessarily have those names. Select the Facility input and Week Ending date picker in Power Apps to find the actual names; do not paste placeholders blindly.

Once the Title card writes the formula result, you can hide that card or show it read-only so users are not invited to edit a value the app owns.

Validate before SubmitForm

If Facility or Week Ending is blank, decide whether to block the save or produce a partial Title. A simple validation pattern around the save button is:

If(
    IsBlank(Trim(DataCardValue_Facility.Text)) || IsBlank(DatePicker_WeekEnding.SelectedDate),
    Notify("Enter Facility and Week Ending before saving.", NotificationType.Error),
    SubmitForm(SharePointForm1)
)

Again, substitute your control and form names.

Publish the custom form

Save and publish the form back to SharePoint, then test:

• create, edit and view modes;
• required-field errors;
• mobile layout;
• users who have normal list permission but no maker rights;
• changing one of the source fields on an existing item; and
• what happens if the custom form is unavailable.

The Title value changes on edit only if the form submits the new calculated result. Decide whether Title should track future source-field edits or preserve the original label.

Option 4: update Title with Power Automate

Power Automate is useful when several creation paths feed the list and you cannot guarantee they all use the custom form.

A basic design is:

1. Trigger when an item is created.
2. Read Facility and Week Ending from the trigger.
3. Compose the desired Title.
4. Update the same item.

Use dynamic content for the fields where possible. A typical expression pattern is:

concat(
  triggerBody()?['Facility'],
  ' - ',
  formatDateTime(triggerBody()?['Week_x0020_Ending'], 'yyyy-MM-dd')
)

The property names must match the trigger output from your list. Run a test and inspect the raw inputs rather than guessing internal names.

Avoid a self-triggering loop

If you use When an item is created or modified, the flow's own update can trigger it again. Microsoft identifies this as a common anti-pattern.

Prefer When an item is created if Title only needs to be set once. If Title must follow later edits, add an explicit trigger condition or compare the current Title with the desired Title and terminate when they already match.

For example, the flow can:

1. Compose DesiredTitle.
2. Check whether the current Title equals DesiredTitle.
3. Update only when they differ.

That turns a potential loop into one follow-up run that exits without another write.

Understand the failure gap

The list item exists before the flow completes. For a short period—or permanently if the run fails—Title may be blank or stale.

That matters when another automation starts immediately after item creation, a required downstream system reads Title, or the Title participates in a unique business rule. Monitor failed runs and decide how support will repair missed items.

For high-consequence writes that must be atomic with create, a post-save cloud flow may be the wrong architecture.

Should you hide or rename Title?

If the organisation does not use Title, you can remove it from normal views and hide it from the list form. Microsoft documents hiding a form column as a reversible display choice; it does not delete the field or its data.

You can also rename the default column's display label. Microsoft notes that a renamed default column can still appear under its original name in list settings because the UI label and default field identity are different.

That is another reason not to pretend Title has become a different type. If you need a true custom calculated field, create one and give it an honest name.

Which option should you choose?

Requirement	Best starting point
Make the list view easier to scan	Column formatting
Reusable same-row calculated value in its own field	Calculated column
Store Title during a controlled user save	Power Apps custom form
Populate Title across several creation routes after save	Power Automate
Title is irrelevant	Hide it from the form/view and use a named custom field

For a small internal list, the simplest reliable design usually wins. Do not add Power Apps and a flow merely to avoid admitting that a separate Display title column is clearer.

Common problems

The JSON looks right but Title is still blank elsewhere

Column formatting is display-only. Check the actual item data or export. Use Power Apps or Power Automate if the stored Title must change.

The formula cannot see a lookup or another list

SharePoint calculated columns work with supported columns in the same row. Use a flow or redesign the data model when the value lives elsewhere.

The Power Apps formula errors after copying it

Control names are generated per app. Replace the sample names with the controls in your form and check the site's locale/date requirements.

The flow keeps running after its own update

Use the created-only trigger where possible. Otherwise compare current and desired values or add a trigger guard so the update does not repeat.

Existing items still have old Titles

Decide whether to backfill them. Test a batch process on copied data, record the old values and avoid changing Title if downstream links or processes rely on it.

Related guides

If users should run a controlled action from a row, use the SharePoint list-button pattern. If the logic belongs in a larger canvas app, the Power Apps time-tracker guide demonstrates keeping an exact SharePoint record rather than looking it up by a non-unique title.

Make SharePoint behaviour predictable

The Teams, SharePoint & Intranet Mastery Space brings together practical patterns for lists, forms, permissions and the details that make Microsoft 365 supportable.

Microsoft sources used

• SharePoint column formatting
• Formatting syntax and cross-field references
• Examples of common formulas in lists
• Create a custom SharePoint form with Power Apps
• Power Apps integration with SharePoint
• Avoid self-triggering Power Automate flows
• Show or hide form columns
• Why a renamed default column keeps its original identity

Source boundary: Microsoft documents display formatting, calculated-column formulas, SharePoint custom forms and flow-loop safeguards. The sample expressions are patterns: internal field names, Power Apps control names, locale and governance differ by list and tenant.