Downgrading User Roles in Amazon QuickSight: Two Reliable Methods Explained

In day-to-day permission management for Amazon QuickSight, administrators frequently encounter a need that seems straightforward but lacks an official shortcut: downgrading a user from Admin or Author to Reader. Surprisingly, the Amazon QuickSight console does not offer a direct role-downgrade path, which makes enforcing permission convergence and the principle of least privilege more difficult than it should be.

This article covers two verified downgrade approaches — the manual "delete and recreate" method, and a safer AWS CLI step-by-step downgrade workflow that preserves the user's asset ownership while reducing their role.

Why Downgrading a Role Is So Awkward

In most permission systems, elevating and reducing role privileges should be symmetrical operations. However, the Amazon QuickSight console only exposes forward-facing actions such as inviting users and promoting roles — it does not surface "downgrade" directly in the UI.

This means that when a team member's responsibilities change, or when security and compliance requirements call for tighter permissions, an administrator cannot complete a downgrade with a few button clicks. Simply deleting the user carries its own risks — dashboards and analytics assets owned by that user may be lost or transferred unexpectedly. Understanding this limitation is a prerequisite for choosing the right downgrade method.

Amazon QuickSight is AWS's cloud-native business intelligence service with four built-in user roles: Admin, Author, Reader, and No Subscription. Admin holds the highest privileges and can manage users and subscriptions; Author can create and edit dashboards and datasets; Reader can only view shared content and cannot create or edit anything; No Subscription means the user does not occupy a license seat. QuickSight's billing model is directly tied to roles — Authors and Admins are billed monthly, while Readers are billed per session — so role downgrading is not just a permission-control concern but is often linked to cost optimization as well. Because roles are deeply coupled with billing and asset ownership, QuickSight imposes certain restrictions on role changes by design, making the "downgrade" path considerably more complex than the "upgrade" path.

Method 1: Manual Delete and Recreate

The most straightforward approach is to delete the target user and then re-invite them with the Reader role. This method has a low operational barrier, requires no command-line environment, and is suitable for one-off, small-scale permission adjustments.

How It Works

• Delete the existing Admin or Author user in the console
• Re-send the invitation with the Reader role
• Once the user accepts the invitation, they receive the restricted permissions

Risks to Be Aware Of

The core risk with this method is asset ownership. If the deleted user owns dashboards, datasets, or other assets, the deletion may cause ownership assignment issues. Before proceeding, always confirm whether the user holds any critical assets, and transfer ownership to another member in advance if necessary. For "clean" users who do not own any assets, this is the fastest path.

Method 2: AWS CLI Step-by-Step Downgrade

For scenarios involving asset ownership, or where operational safety is a priority, the recommended approach is a step-by-step downgrade using the AWS CLI. Compared to direct deletion, the CLI workflow preserves the user's asset ownership while adjusting their role, avoiding confusion over data and dashboard attribution.

Why It Is Safer

The CLI approach fundamentally works by modifying the user's role attribute in place through a programmatic interface, rather than destroying and recreating the user. This preserves the user's ID and asset bindings — only the permission level changes. For production environments and large-scale team management, this is the more reliable choice.

When to Use It

• The user owns important assets such as dashboards or datasets
• You need to handle multiple users in bulk or via scripting
• The scenario demands auditability and repeatability for compliance purposes

The core AWS CLI command for modifying a QuickSight user's role is aws quicksight update-user, which requires the --aws-account-id, --namespace, --user-name, and target --role parameters (valid values: READER, AUTHOR, or ADMIN). A typical downgrade command looks like this:

aws quicksight update-user \
  --aws-account-id 123456789012 \
  --namespace default \
  --user-name user@example.com \
  --role READER \
  --email user@example.com

Before running this command, ensure that your local environment is configured with IAM credentials that have the quicksight:UpdateUser permission. The --namespace value defaults to default; if your organization uses multi-namespace isolation, fill in the appropriate value. This command modifies the user in place and does not trigger a delete or re-invite flow, so the user's existing asset bindings are unaffected.

Choosing the Right Approach

Both methods have their place. If you are only dealing with temporary users who have no asset associations, the manual delete-and-recreate approach is fast enough. However, as soon as asset ownership is involved, or when operating in a production environment, the AWS CLI step-by-step downgrade is the truly reliable option.

Ultimately, this case reflects a common reality in cloud service permission management: the console UI does not always cover every operational path, and the command line and APIs often provide more complete and granular control. Administrators should include the CLI as a standard tool in their permission workflows rather than relying solely on the graphical interface.