Replace an existing dashboard greyed out for co-owner

Hi! I’ve been trying to share my analysis to publish changes I did into an existing dashboard but the option to “replace an existing dashboard” is greyed out for me.
Based on comments on other similar issues from the community, I’ve gone ahead and checked to be sure that I am indeed the co-owner for both the dashboard as well as the analysis and even know that have rights to edit the underlying dataset.
I also tried editing and publishing an analysis into the existing dashboard that I myself authored and the option was greyed out there as well, so I am thinking this is something to do with my user as a whole. I am an admin, but do I have to be logged in or managing this with my IAM user instead perhaps? Or is there something else I should look out for/get adjusted in order for my user to be allowed to publish analysis changes to the original dashboard?

Are you sure it’s the same analysis that was originally linked to the publishing of that dashboard and it’s not a copy from a dashboard?

You can only overwrite dashboards where that analysis was the original analysis that made that dashboard.

Yes, definitely the same, original analysis in both of the attempted cases.

One more note that I just thought of, that may or may not affect things. So far, we’ve been pushing analysis changes to dashboards via this somewhat elaborate SDK process, involving some Python scripts, Docker container and git review process. If the previous instance of creating the dashboard from an analysis happened via that process (though initiated by me), perhaps that could be the underlying reason? That somehow Quicksight does not understand it as its original analysis when worked on within the UI (even if it works just fine if changed via the same SDK process).


if you are already familiar with python and SDK, can you check with the Quicksight API, if you really have the required permissions in the dashboard?

With describe_dashboard_permissions you can check the permission of a dashboard you are owner of and compare it with the permissions you have in the other dashboard. With update_dashboard_permissions you can give your user the required permissions.

1 Like

I’ve checked already though, I am indeed co-owner of the dashboard, as well as analysis, so I don’t see that being the issue here.


another idea: have you or another admin deleted the dashboard and then created one with the same name?



That’s a good point. The exact one I initially had the problem on I cannot be 100% sure without checking with the whole team, but the other one that I authored was definitely not re-created, it’s the original dashboard as is and still having issues.
I will revise the exact SDK steps to be sure that nothing in there could even remotely be considered by QS as deletion/re-creation as way of its normal procedure and try creating a new analysis+dash from scratch within the UI just to exclude the SDK process as the culprit. Will report back to the community shortly.

you can check with describe_dashboard which analysis was used to create the dashboard. SourceEntityARN is the ARN of the analysis.

1 Like

Hi all, for any future searches and references - it is the SDK process that’s to blame here. When I created a new dataset, analysis and dashboard all within UI, I was successfully able to then push any further analysis changes into the dashboard without issues.
I am yet to understand what exactly in our SDK process forces this limitation onto the UI management, but am looking into that now. Thanks for thinking along!

1 Like

It seems the issue is to do with the fact that our SDK process pushes changes via the IAM user credentials of a user while the UI logins are email based. This seems to cause an incompatibility and “throws” the system off.