Power Automate Import Failure: ‘GetTable’ failed with status code ‘Unauthorized’

‘GetTable’ failed with status code ‘Unauthorized’

Recently, one of our business users had left the firm, and handed over the canvas apps he was developing to his colleagues. There was one canvas app with flows that update SharePoint list. He had shared the app .zip file with the team and told, it’s a completed app and just needs to import to the target environment after creating the SharePoint list. So, the team didn’t bother much to collect further details about the source tenant where this was developed. He had created the app on a trail tenant which was tied with his account and was lost as soon as he left the firm.

But, the business users were unable to import the app and came to us with the below error.

Flow save failed with code
'DynamicOperationRequestClientFailure' and message
'The dynamic operation request to API 'sharepointonline' operation 'GetTable' failed with status code 'Unauthorized'. 
This may indicate invalid input parameters.
Error response: { "error_description": "Exception of type 'Microsoft.IdentityModel.Tokens.AudienceUriValidationFailedException' was thrown." }'.

The Issue

The issue here was the SharePoint site dependency. The definition.js files of the Power Automate flows had references to the old site and the current user does not have access to the original site, hence the flow was failing with error ‘Unauthorized’ even though, SharePoint connection was created in the target environment.

The Fix

The fix was to edit the definition.js file and replace the SharePoint URL and List ID with the new site information. The definition.js file is in the exported zip file. We had to replace all the occurrence of the URL, list ID (defined under table) and view ID, and saved the definition.js file and copied it to the zip file. Importing the updated zip file worked.

{"dataset":"https://***.sharepoint.com/","table":"d2**826-e05a-4972-be****8","view":"**-27f2-4ace-a289-ef41a**"}

The Right Way

This is a known issue when moving PowerApps/ Power Automate to a new tenant. This behaviour is not consistent as some flows were imported with no errors and others were rejected due to Unauthorized exception on GetTable().

One way to avoid this issue, is to use variables instead of directly selecting the SharePoint site, list and view in the SharePoint actions inside your flow.

Another option is to use environment variables in your flow. This will also help us avoid direct SharePoint references in your flow.

Hope this helps.

If you know any alternate option to handle this, please let us know in the comments.

I Wish I Would Have Known #24: Bypass User Consent Pop-up

Every time when a user runs a powerapp with connectors for the first time, they will receive a popup asking their consent to use the connectors in the specific app.

User Consent Pop-up

Use the Set-AdminPowerAppApisToBypassConsent cmdlet to bypass this pop-up, so that users are are not required to authorize API connections for the input app. The command changes the bypassConsent flag of an app to true. Using this command, end users will observe consent is bypassed for First Party connectors that support single sign-on and custom connectors that don’t require authentication. This includes custom connectors with or without a gateway. Read more here.

I Wish I Would Have Known #23: Could Flow Run Succeeded after Showing Timeout Message.

It’s known behavior that, if you test a cloud flow that runs for longer than 10 minutes, you may get a timeout message in Power Automate, even though the flow continues to run in the background. If this happens, reopen the view to receive the current status.

I Wish I Would Have Known #22: Environment Type and Backup Retention Period

Changing an environment type to sandbox will immediately reduce backup retention to 7 days. If you do not need backups (restore points) older than 7 days, then you can safely switch the type. If you think you may need restore points older than 7 days, it is recommended that you keep the environment as production and consider restoring to a different environment of type sandbox. Read more on the official docs here.

I Wish I Would Have Known #21: Add new Area to Sitemap in Modern Model-Driven App Designer.

The new modern model-driven app designer has an easy to use interface, and in sync with canvas app designer. However, the preview has the following known limitations.

  • You can’t add the following model-driven app components:
    • URLs
    • Business process flows
    • Charts
  • You can’t add more than one area to the app’s navigation site map.
  • You can’t change the app’s icon.
  • You can’t specify the app’s URL.

You can use the Switch to classic option to use the classic designer to complete the above app design tasks.

Don’t be like our Buddy in the above comic strip, always check the official docs to see the known limitations, read more here.

I Wish I Would Have Known #20: Get the list of new apps and flows in your tenant.

Sometimes, the most useful things may go unnoticed, this FLOW template can  provide a list of new apps, flows, and connectors that have been introduced into your tenant within a configurable window. This is very useful when you are an admin and have to do some house keeping activities in the tenant.

I Wish I Would Have Known #19: Maker Portal: User Cannot See an Environment

Sharing an app with the user and, asking the user to run the app for one time will resolve this issue for most cases. I have had few instances where, new users with maker roles were unable to see the environment in the maker portal even after sharing the app. However, sharing a sample App with Co-owner permission resolved this issue.

I Wish I Would Have Known #18: Delete Permission for Model-Driven Apps

The underlying structure of Model-Driven apps are totally different than Canvas apps. Model-Driven apps are created at environment level and owned by the organization so, if you need to give delete permission for model-driven apps, it should be given at the environment level. Means, this will give the permission to delete apps created by other users as well. This is the main reason why Model-Driven app delete permission is restricted to admin roles.

I Wish I Would Have Known #17: Environment Backup Retention Periods

Backups for production environments that have been created with a database and have one or more Dynamics 365 applications installed are retained up to 28 days. Backups for production environments which do not have Dynamics 365 applications deployed in them will be retained for 7 days. Sometimes, this can be a bit confusing but, very important to understand the differences, read more from official docs here.