--- title: "Dealing with User Role IDs in Features · Appnovation" url: "https://www.appnovation.com/insights/dealing-user-role-ids-features" description: "Feature works locally but breaks after deploy? How to deal with mismatched user role IDs when exporting Drupal Features across environments." --- Article # Dealing with User Role IDs in Features ![Dealing with User Role IDs in Features](https://cdn.sanity.io/images/ey850001/production/9707256cd773c831fe31132fd54d7647cfe96aaa-680x200.jpg?w=1400&auto=format) Anyone who uses [Features (opens in new window)](https://drupal.org/project/features) to deploy code to different development environments has probably encountered this issue at one point or another: Your feature works fine on your local environment, but once deployed, just refuses to work. There are a few things you could look for, and one of those is user role IDs. As of this writing (Drupal 7), user roles have no machine names, rather, they are identified by role IDs. The issue here is that the same role ID could mean different roles on different environments. So if your feature export includes user role IDs, once they are imported on a different environtment, if you're lucky, the feature will just not work because there are no such role IDs. If you're really unlucky, then you might end up associating the feature with the wrong role, such as giving administrative power to someone you shouldn't. Two common modules that export user roles by their IDs are [Views (opens in new window)](https://drupal.org/project/views) and [Rules (opens in new window)](https://drupal.org/project/rules). Fortunately for us, they do provide a way to alter their values before importing through: [hook\_views\_default\_views\_alter() (opens in new window)](https://api.drupal.org/api/views/views.api.php/function/hook_views_default_views_alter/7)and [hook\_default\_rules\_configuration\_alter() (opens in new window)](http://drupalcontrib.org/api/drupal/contributions!rules!rules.api.php/function/hook_default_rules_configuration_alter/7). In these hooks, you can set the role ID values to the appropriate role IDs of the local environment. This is not a perfection solution because you are, essentially, hardcoding your logic (role) in your code. If for any reason, you decide to change the roles in your Views/Rules (from the UI) and re-deploy again, you need to go back to your code and update it with the corresponding roles. Otherwise, it will override whatever changes you made. That was two modules out of the thousands of modules that Drupal has. That's great, but what about the rest of the modules that don't provide a way for us to modify their exports? For modules that store their configurations in Drupal's variable table, [Strongarm (opens in new window)](https://drupal.org/project/strongarm) provides a way to export those settings into features. However, you're still running into the issue of roles being exported by their IDs, rather than role names. A simple [patch (opens in new window)](https://drupal.org/files/strongarm-2076543-import-export-value-alter-hooks.patch) to the strongarm module allows you to hook into the export (hook\_strongarm\_export\_value\_alter()) and import (hook\_strongarm\_import\_value\_alter()) processes of strongarm. One way to do this is in hook\_strongarm\_export\_value\_alter(), convert role IDs into role names. Then in hook\_strongarm\_import\_value\_alter(), convert role names back to role IDs. The great thing about this is that you're not hardcoding anything. Any changes from the development environment will be captured by hook\_strongarm\_export\_value\_alter() automatically, and hook\_strongarm\_import\_value\_alter() will just convert it back when you deploy it. So until Drupal has a way of persisting user role identifers across environments, \*\_alter() away. ## Keep reading [![What is Sovereign AI](https://cdn.sanity.io/images/ey850001/production/a5889abdd5e80376912546622e046e3fbef234b4-2496x1664.png?w=640&auto=format)](/insights/what-is-open-source-sovereign-ai.md) Article · 7 min AI ### [What Is Open Source, Sovereign AI?](/insights/what-is-open-source-sovereign-ai.md) Every company is encouraging more AI, and almost every AI bill is climbing. Sovereign AI is about two kinds of control: over your data and over your costs. Here's why open source sits at its foundation. [Iain MacNeil](/people/iain-macneil.md) Article [![AI-first experience design](https://cdn.sanity.io/images/ey850001/production/8bbc2418e87924ef10f36115478a2e10d5bed95e-1584x624.jpg?w=640&auto=format)](/insights/how-build-ai-first-experience-without-throwing-out-everything-youve-already-built.md) Article · 6 min AI Sep 10, 2026 ### [How to Build an AI-First Experience Without Throwing Out Everything You've Already Built](/insights/how-build-ai-first-experience-without-throwing-out-everything-youve-already-built.md) Users now expect a direct answer, not a list of links to click through. Here's how organizations can layer an AI-First experience onto their existing website or app, in weeks rather than years. [Andrew Douglas](/people/andrew-douglas.md) Article [![What Becomes Possible When AI Can Read All the Data](https://cdn.sanity.io/images/ey850001/production/c28ab0bd26753421ee42937e13adc7a7f19b47f0-1296x510.jpg?w=640&auto=format)](/insights/what-becomes-possible-when-ai-can-read-all-data.md) Article · 4 min AI Sep 09, 2026 ### [What Becomes Possible When AI Can Read All the Data](/insights/what-becomes-possible-when-ai-can-read-all-data.md) Most of the world's data has never been analyzed, only sampled. AI changes that. How AI-ready data platforms unlock questions no one could ask before. [Appnovation](/people/appnovation.md) Article ## Get the thinking, *before everyone else.* One considered email a month. New essays, field notes from live engagements, and the occasional strong opinion. No noise.