diff --git a/docs/02.deploying/01.production/03.details/03.details.md b/docs/02.deploying/01.production/03.details/03.details.md
index 04720ca81..775d9865e 100644
--- a/docs/02.deploying/01.production/03.details/03.details.md
+++ b/docs/02.deploying/01.production/03.details/03.details.md
@@ -24,6 +24,9 @@ slug: /deploying/production/details
 * CUSTOM_CHECK_CONTROL
 > (Optional) Used to enable/disable ability to create custom compliance scripts in containers/hosts. Values are "disable" (default, not allowed), "strict" (admin role only), or "loose" (admin, compliance, and runtime-policy roles).
 
+* NV_ENABLE_CUSTOM_SVC_NAME
+> (Optional) Set the value to "1" (or "true") to allow a workload to specify its NeuVector service/group via the `io.neuvector.service.name` label. Because the label is evaluated by both the controller and the enforcer, this variable must be set on **both** components. See [Overriding a Workload's Service](/policy/groups#overriding-a-workloads-service) for details.
+
 * AUTO_PROFILE_COLLECT
 > (Optional) Set value to 1 to enable collection of memory profile data to help investigate memory pressure issues.
 
diff --git a/docs/05.policy/04.groups/04.groups.md b/docs/05.policy/04.groups/04.groups.md
index 614eb9a64..4e1216b3e 100644
--- a/docs/05.policy/04.groups/04.groups.md
+++ b/docs/05.policy/04.groups/04.groups.md
@@ -95,6 +95,29 @@ After saving a new group, NeuVector will display the members in that group. Rule
 
 Custom groups can support virtual host based address groups. This enables a use case where two different FQDN addresses are resolved to the same IP address, but different rules for each FQDN should be enforced. A new custom group with ‘address=vh:xxx.yyy’ can be created using the ‘vh:’ indicator to enable this protection. A network rule can then use the custom group as the ‘From’ source based on the virtual hostname (instead of resolved IP address) to enforce different rules for virtual hosts. 
 
+#### Overriding a Workload's Service
+
+By default, NeuVector derives the service (and the corresponding learned group, prefixed with `nv.`) for each workload from orchestration metadata such as the deployment/pod name. A workload can override this derivation by setting the label `io.neuvector.service.name` on the container or pod. For example, a pod labeled `io.neuvector.service.name=myapp` in namespace `prod` is placed into the group `nv.myapp.prod` regardless of its pod name.
+
+On Kubernetes the label value is lowercased and normalized to DNS-1123 form before use, so `io.neuvector.service.name=MyApp` results in the group `nv.myapp.prod`.
+
+:::warning
+Honoring this label is **disabled by default**. NeuVector ignores `io.neuvector.service.name` unless the feature is explicitly enabled.
+:::
+
+To enable it, set the environment variable `NV_ENABLE_CUSTOM_SVC_NAME` to `"1"` (or `"true"`) on **both** the Controller and the Enforcer. Both components evaluate the label, so setting it on only one leads to inconsistent group assignment. With the Helm chart, add the variable to the `controller.env` and `enforcer.env` passthrough lists in your values file:
+
+```yaml
+controller:
+  env:
+    - name: NV_ENABLE_CUSTOM_SVC_NAME
+      value: "true"
+enforcer:
+  env:
+    - name: NV_ENABLE_CUSTOM_SVC_NAME
+      value: "true"
+```
+
 ### Custom Group Examples
 
 #### General Criteria