Power Platform Community Forum Thread Details

Short answer: no — you can’t rename those SQL stored procedure data sources, and yes, this is a known (and very annoying) limitation.

What you’re seeing is by design, not a bug.

Why this happens

In Power Apps there’s an important distinction that isn’t obvious in the UI:

Tables / Views → appear as named data sources
Stored Procedures → are treated as operations, not entities

When you add a stored procedure, Power Apps creates an auto-generated internal data source name, typically:

[SqlServerName].[DatabaseName].[dbo].[TableName]_123

That trailing number is just an internal ID to avoid collisions.
Power Apps does not expose a rename option for these operation-based connections.

So unlike tables/views:

❌ no friendly name
❌ no alias
❌ no display name override
❌ no stored procedure name shown in the Data pane

This has been a long-standing complaint from makers who use SP-heavy apps.

Why Microsoft did it this way

Stored procedures are surfaced through the SQL connector as callable actions, not schema objects. Internally they are closer to:

Power Automate SQL actions
Custom connector operations

The Canvas App designer simply never added a naming abstraction layer for them.

So unfortunately: what you see is what you get.

What you can do (practical workarounds)

None are perfect, but these are what experienced builders do.

✅ 1. Centralize calls in a wrapper pattern (recommended)

Instead of calling stored procedures directly everywhere:

Create a single helper formula (or screen-level logic)
Comment it heavily
Reference it consistently

Example pattern:

// Submit Order
Set(
    varSubmitOrderResult,
    '[dbo].[Orders]_123'.Run(
        paramOrderId,
        paramUserId
    )
);

Then keep a commented mapping at the top of the app or in a note screen:

// SP Mappings:
// [dbo].[Orders]_123  → usp_SubmitOrder
// [dbo].[Orders]_456  → usp_GetOrderSummary

Crude, but effective.

✅ 2. Use naming discipline in SQL itself

While the data source name won’t change, you can reduce confusion by:

using very distinctive stored procedure names
grouping them logically (e.g. prefixes)

Example:

usp_App_GetUserProfile
usp_App_SaveUserProfile
usp_App_SubmitRequest

Then when you inspect the .Run() parameters or hover in formulas, it’s easier to infer which SP you’re calling.

✅ 3. Move SP calls behind Power Automate (cleaner UX)

For larger apps (20+ stored procedures), many teams do this:

Power Apps
   → Power Automate flow
       → SQL Stored Procedure

Benefits:

Flows can be renamed properly
App only shows meaningful flow names
Easier governance and debugging
Better error handling

Downside:

Extra hop
Slight performance overhead

But from a maintainability perspective, this is often worth it.

✅ 4. Custom connector (advanced)

If you really want control:

Create a custom connector
Expose each stored procedure as a named operation

Then your data pane looks like:

GetOrderSummary
SubmitOrder
UpdateUserProfile

This is the only way to get first-class naming today.

Downside:

More setup
Requires API layer or Azure Function in front of SQL

What you cannot do

Just to be explicit:

❌ Rename SQL stored procedure data sources
❌ Alias them in the Data pane
❌ Change how they appear in the connection list
❌ Make them display like tables/views

If someone tells you otherwise, they’re confusing this with Power Automate or custom connectors.

Why this hurts at scale

You’re absolutely right that with ~20 stored procedures:

discoverability tanks
onboarding new devs is painful
mistakes are easy
refactoring is risky

This is one of those areas where Canvas Apps clearly shows its “low-code origins”.

Summary

Power Apps does not support renaming SQL stored procedure data sources
They are treated as operations, not entities
The numeric suffix is unavoidable
Best options are:
- wrapper patterns
- Power Automate indirection
- or a custom connector