Dataverse table metadata resolution fails when dataSourceName uses logical table name instead of generated TypeScript alias

Question

We found what appears to be a bug, or at least an undocumented platform limitation, in the App Gen / Power Apps generated runtime when working with Dataverse table metadata resolution.

Summary

The application is connected to a Dataverse table whose correct logical name is:

• crae0_sd_usuario

However, runtime calls that use this table name fail with the following error:

No table metadata was found for '{"options":{"dataSourceName":"crae0_sd_usuario"}}'

The issue occurs even though the table is correctly added in the app data configuration and the generated metadata already contains references to the same Dataverse table.

Observed error

Error: No table metadata was found for '{"options":{"dataSourceName":"crae0_sd_usuario"}}'
    at getTableMetadata (data/common/table-metadata-utils.ts:59:11)
    at data/app-gen-data-client.ts:201:37
    at withScenarioLogging (data/common/logger-client.ts:43:26)
    at AppGenDataClient.retrieveMultipleRecordsAsync (data/app-gen-data-client.ts:194:12)
    at DataverseUsuarioService.getAll (services/dataverse-usuario-service.ts:24:38)
    at hooks/use-sync-users.ts:91:61

Expected behavior

If a Dataverse table is configured in the application and its metadata exists in the generated runtime, calls using the real Dataverse table logical name should resolve correctly.

At minimum, the tool should document clearly whether runtime APIs expect:

• the Dataverse logical name
• the plural entity set name
• or a generated TypeScript alias such as SdUsuario

Actual behavior

The runtime only resolves the table when using the generated TypeScript model/interface alias, not the actual Dataverse logical table name.

In this case:

• Real table logical name: crae0_sd_usuario
• Metadata table id found in generated artifacts: crae0_sd_usuario
• Data table id found in generated artifacts: crae0_sd_usuarios
• TypeScript alias expected by runtime: SdUsuario

If the app uses crae0_sd_usuario as dataSourceName, metadata lookup fails.

Why this appears to be a bug or tooling limitation

The generated runtime metadata already contains the correct Dataverse table identifiers, but the lookup logic appears to match only against typescriptModelInterfaceName.

The problematic logic is effectively:

if (options.dataSourceName) {
  tableMetadata = dataModelConfig.tableMappings.find(
    (x) => x.typescriptModelInterfaceName === options.dataSourceName,
  );
}

Because of this, the runtime rejects valid table identifiers such as:

• crae0_sd_usuario
• crae0_sd_usuarios

and only accepts:

• SdUsuario

This creates a mismatch between:

• Dataverse logical table name
• generated metadata identifiers
• runtime resolution rules
• developer expectations
• app configuration names shown in the tool

Impact

This issue prevents basic CRUD or synchronization operations from working even though:

• the Dataverse table is configured
• the app builds successfully
• the generated metadata already includes the correct table
• the frontend is using the real Dataverse logical name

It results in an application that appears correctly configured but fails at runtime with metadata resolution errors.

Reproduction steps

1. Add a Dataverse table to the app data sources.
2. Use the real Dataverse logical name as the table identifier in runtime data access:
   • crae0_sd_usuario
   1. Call a generated or custom service method such as:
      • retrieveMultipleRecordsAsync("crae0_sd_usuario", ...)
      1. Run the app.
      2. Observe runtime failure:
         • No table metadata was found for '{"options":{"dataSourceName":"crae0_sd_usuario"}}'

Additional observation

Even after removing and re-adding the Dataverse table in the app data configuration, the generated runtime still kept the alias-based resolution behavior and did not align lookup to the actual logical table name.

This suggests one of two things:

1. The runtime has a bug in metadata resolution.
2. The platform intentionally requires generated aliases but does not document that requirement clearly enough.

Requested clarification / fix

Please confirm whether this is:

• a product bug
• a generation bug
• or a platform limitation by design

If by design, please document clearly which identifier must be used in runtime APIs:

• Dataverse logical name
• entity set name
• generated TypeScript model name

If this is a bug, a likely fix would be for metadata resolution to accept multiple valid identifiers, for example:

• typescriptModelInterfaceName
• apiMetadataTableId
• apiDataTableId
• configured datasource key

Suggested improvement

The metadata resolution logic should accept any of the valid identifiers already present in the generated metadata model, instead of only matching the generated TypeScript alias.

That would make the runtime more robust and consistent with developer expectations.

Environment

• Power Apps / App Gen generated web app
• Dataverse-backed table
• Runtime metadata includes:
  • apiMetadataTableId = "crae0_sd_usuario"
    • apiDataTableId = "crae0_sd_usuarios"
      • typescriptModelInterfaceName = "SdUsuario"