Who is this article for?

Support engineers who investigate and resolve group deactivation issues, and administrators who manage and configure workflows.

Support permissions or Administrator permissions are required.

This article explains why a group may fail to deactivate or delete because of a workflow Responsible Party reference, how to diagnose the true cause, and how to resolve it either in the application or, as a last resort, in the database.

Issue

When you try to delete or deactivate a group that is tied to a workflow, you will see an error message similar to: "This group is currently used in a workflow, either directly as the responsible party in the workflow definition or indirectly as the responsible party via a custom field in a workflow instance. Please refer to the group summary report in Common Scripts for more details.".

The numbers at the end of the error message are workflow definition IDs. Customers sometimes report that clicking through to the referenced workflow returns Access Denied, leading them to conclude the workflow has been deleted. This is frequently not the case — the workflow may still exist but be Offline and hidden by security settings.

Understanding the actual cause

In the reference case for this issue, the referenced workflow definition had not been deleted — it had been taken Offline. Two separate mechanisms combined to produce the customer's symptoms.

Important: Do not assume the workflow has been deleted just because the customer cannot see it or reports it as deleted. Always confirm the workflow's actual Enabled/Offline status and its Definition Access list before escalating. In the reference case, initial triage (and the customer's own description) both assumed deletion, which was incorrect and delayed resolution.

Identifying referenced groups

To identify where the group is referenced:

1. Go to Common Scripts.
2. Navigate to Group Summary.
3. Select the relevant group.
4. Click View Summary.

The summary will display all locations where the group is currently being used, including workflow definitions and custom fields.

Running diagnostic queries

Confirm the underlying mechanism before proposing a fix. The following read-only checks help establish the true cause:

• WF_Workflows — confirm Enabled (0 = Offline, not deleted) and ShowInTree for the workflow ID named in the group-disable error.
• WF_ResponsibleParties — find the row(s) matching the relevant StateId (step) and ObjectId (group). Check IsField: 0 = fixed Responsible Party (blocks deactivation as designed), 1 = Personnel custom field reference (does not block in the same way).
• SC_Security — check the Definition Access entries (ObjectId = the workflow definition ID) to see which group(s) are permitted to view/edit the definition. Compare against the customer's own group membership.

Applying the preferred resolution — in-application fix

Whenever the workflow has any possibility of being used again, or you cannot confirm it is safe to alter directly in the database, prefer the in-application fix. This is always the safer option since it goes through normal application validation and leaves an audit trail via the application's own change tracking.

If the workflows listed in the Group Summary are accessible in your system, an administrator can remove the group reference directly.

To remove the group from the workflow definition:

1. Identify who is a member of the workflow's Definition Access group(s), or find an administrator with an Alter Security override.
2. Have that user open the workflow definition (it is Offline, so it is directly editable).
3. Locate the step where the group is set as a fixed Responsible Party.
4. Remove the group from that step's Responsible Party field.
5. If the group is referenced in a custom field, remove it from that field.
6. Click Save changes.
7. Confirm the customer can now deactivate the group.

Deleting groups

After the workflow reference has been removed, you should be able to delete the group without encountering the previous error.

To delete the group:

1. Navigate to your group management area.
2. Locate the group that was previously blocked.
3. Click Delete.
4. Confirm the deletion when prompted.

If you continue to experience issues or discover additional groups with the same problem, open a ticket with us for further assistance.

Applying the last-resort fix — direct database correction

Important — read before using: Only use this when ALL of the following are true:

• No one currently has Definition Access to the workflow and there is no practical way to grant it (e.g. the relevant groups have no active members, or granting access would itself be inappropriate).
• The workflow has zero live instances — confirm via instance count before proceeding. This fix removes a Responsible Party binding at the definition level; it is not intended for workflows with active or historical instances still in use.
• The change is executed by CloudOps/Dev only, following your standard change control process. Support engineers should never run this directly or hand it to a customer to run themselves.

In the reference case, the workflow had never been launched (created as a test, never promoted to production, zero instances), which made a direct removal of the fixed Responsible Party binding a low-risk resolution. The statement used was of the form:

DELETE FROM WF_ResponsibleParties
WHERE StateId = <step_id>
  AND ObjectId = <group_id>
  AND IsField = 0;

• StateId — the specific workflow step ("state") where the group is bound as a fixed Responsible Party.
• ObjectId — the group's internal ID.
• IsField = 0 — confirms you are removing a fixed Responsible Party binding, not a Personnel custom field reference. Do not run this against a row where IsField = 1; that is a different reference type and removing it this way is not the correct mechanism.

To verify the fix after running the statement:

1. Confirm the group can now be deactivated successfully by the customer.
2. Check that no other Responsible Party bindings for that group remain on other steps of the same or other definitions, if the customer's goal is full deactivation.

Exceptions — orphaned backend references

If the workflows listed in the Group Summary are genuinely not visible or accessible and cannot be edited even after granting Definition Access, the references may be orphaned backend data from previously deleted workflows. This cannot be resolved through standard administrative actions.

To resolve this issue, open a ticket with us, making sure you provide the:

• group name
• workflow definition IDs from the error message

We will remove the orphaned workflow references from your system, at which point you'll be able to delete the groups as normal.