How Do I Assign a Role on WooCommerce Subscription Signup?

How It Works

WordPress's role system is separate from WooCommerce Subscriptions entirely, so connecting the two is a matter of hooking into the subscription status-change events (covered in more depth in the developer hooks question) and calling WordPress's own user role functions. This is a common pattern for gating access to custom content types, a members-only area, or a specific capability based on which subscription a customer holds.

add_action( 'woocommerce_subscription_status_active', function( $subscription ) {
    $user = new WP_User( $subscription->get_user_id() );
    $user->set_role( 'premium_member' );
} );

add_action( 'woocommerce_subscription_status_cancelled', function( $subscription ) {
    $user = new WP_User( $subscription->get_user_id() );
    $user->set_role( 'customer' ); // fall back to the default role
} );

Things Easy to Get Wrong

• Only handling the "active" and "cancelled" transitions, forgetting "on-hold" and "expired" — a customer whose payment failed and moved to on-hold should generally lose the role too, not just fully cancelled customers.
• Using set_role() when a customer might hold multiple roles for other reasons — set_role() replaces all of a user's roles, which can strip something unrelated if they had another role assigned for a different reason. add_role()/remove_role() may be more appropriate depending on the setup.
• Not handling a customer with multiple subscriptions mapping to different roles — cancelling one shouldn't necessarily downgrade a role still justified by another active subscription.
• Forgetting existing subscribers when first adding this logic — a snippet only fires on future status changes, so already-active subscriptions need a one-time manual pass to get the role applied initially.

Building It Properly

1. Map out every relevant status transition, not just active/cancelled, before writing the hook logic.
2. Use add_role()/remove_role() instead of set_role() if customers can hold roles from multiple sources.
3. Handle the multiple-subscriptions-per-customer case explicitly if it applies to your store.
4. Run a one-time backfill for existing subscribers when this logic is first added.

Need this built and tested properly against every status and edge case? See custom WooCommerce development.