Hey @wisefool769! This is indeed expected behavior i.e. the ability for "Developer" and "Project Developer " to update the Alias does not currently exist. If you require a team mate to update an Alias, they would require at least the Team Member role (please see: https://vercel.com/docs/accounts/team-members-and-roles/access-roles/project-level-roles#project-level-permissions)

I can share that a colleague of mine has replied to your support case (#00292943) 🫡 I will leave a note of this thread on the case itself so it can be routed to the right team as a feature request, internally.

For anyone else with a similar Q, I've copied below some potential workarounds:

1. Vercel CLI Alias Command

• Use the vercel alias command to apply custom domains to your deployments

1https://vercel.com/docs/cli/alias vercel alias <deployment-url> <custom-domain> --token member-role-token

OR

2. Separate Tokens for Different Scopes

• Keep your existing token with member role for production deployments and domain assignments.
• Create a new token specifically for preview deployments.
• Use the --env flag to specify the environment when deploying previews:

1vercel --env preview --token preview-token

Hello @rizbizkits ! Thank you for the reply.

The two workarounds you mentioned seem to still require an access token with at least Member-level permissions. Even if I create a new Member-level token specifically for preview deployments, it would seem that nothing prevents someone from using it for production deployments.

I would like Developers to be able to change the alias for any domain currently pointed to a preview branch to point to any other preview branch. Functionality like OAuth is easier to test with static redirect URL's, so it's useful for people to have individual domains for their own feature branches. Then when they're working on a new feature, they can change the branch their individual domain points to.

If we give out Member-level tokens for this purpose, it would defeat the purpose of the separation between Member and Developer. If Developers can push code to preview branches but can't put those branches on a domain, it creates a bunch of low-value administrative work for Members and Admins.

Thank you for creating a feature request! Is there any way to track the progress of that?

If we give out Member-level tokens for this purpose, it would defeat the purpose of the separation between Member and Developer

I see! I am going to consult our Account Management engineers who are more familiar with the design and implementation of the teams/accounts/roles system(s) to understand if they are aware of the points you've shared and whether they have any further suggestions. I'll circle back.

Thank you for creating a feature request! Is there any way to track the progress of that?

There is an internal ticket, currently. A CSM (Customer Success Manager) will reach out to you directly with any progress on the feature request!