[external] Auditing Group Usage in WEBCON Business Rules

External content by Aleksander Damaz

In the previous article, I showed how to check where a specific user has assigned permissions — globally, at the process level, at the workflow/document type level, and at the individual element level.

That, however, doesn’t exhaust the topic of groups in WEBCON. I use AD/Webcon groups not only to grant permissions, but also as task executors, field visibility criteria, or conditions for transitions between steps — in other words, anywhere a Business Rule appears in the system.

The problem I keep running into: in large, long-maintained environments, it’s easy to lose track of where a given group is still being used. After years of maintenance, I don’t always remember why a form section is visible only to a particular group, or why a task in a rarely used process ends up with exactly those people.

On top of that, in large environments configuration changes are a natural, ongoing thing — thanks to the InstantChange™ technology built into WEBCON, process modifications get deployed quickly and often, without downtime. That convenience comes at a price, though: with changes happening this frequently, documentation of which groups are tied to which system functionality quickly goes stale — and sometimes it simply doesn’t exist.

Disclaimer: the queries and helper function described below are the result of my own analysis of the WEBCON database structure — this is not an official WEBCON solution. They show the most common places where groups are used in business rules, based on what I’ve observed in practice. In your environment, depending on the system version and configuration, the list of places where a group is used may be different or broader — treat this as a starting point for your own audit, not as a closed checklist.

Mechanism: the ADC_GetGroupBusinessRules Helper Function

Business Rules in WEBCON can call one another — for example, a rule that determines a task’s executor might use a helper rule that checks group membership. To find all rules connected to a given group — not only the ones where the group is entered directly, but also the ones chained to them — I put together a helper function:
 

ADC_GetGroupBusinessRules (link to github)

What this function does, step by step:

• I look for the anchor point — rules where the group’s unique identifier appears directly in the assigned-people field (BRD_People) or in the rule definition content (BRD_BasicDesignerJson).
• I expand the result recursively — if a rule found this way is called by another rule (a parent–child relationship), that second rule also lands in the result. And so on, in both directions, until the chain of connections is exhausted.
• I guard against cycles — in case rules reference each other in a loop, the function won’t fall into an infinite loop.

Important: I pass the group’s unique identifier (BPSID/GUID) into the function, not its display name. This protects against a situation where a text-fragment search would accidentally catch a different group with a similar name.
 

Three Places Worth Checking for Group Usage

1. Group Used in an Action
 

SELECT
    'UseInAction' as Type,
    INact.ACT_ID AS ACT_ID,
    EnglishName as ActionType,
    INact.ACT_Name as ActionName,
    def.DEF_Name AS Process,
    app.APP_Name AS Application
FROM WFBusinessRuleDefinitions BRD_INAction
JOIN WFActionBusinessRules a ON a.ABR_BRDID = BRD_INAction.BRD_ID
LEFT JOIN WFActions INact ON INact.ACT_ID = a.ABR_ACTID
LEFT JOIN WFDefinitions def ON def.DEF_ID = BRD_INAction.BRD_DEFID
LEFT JOIN WFApplications app ON app.APP_ID = def.DEF_APPID
LEFT JOiN DicActionKinds on INact.ACT_ActionKindID = TypeID
WHERE
    INact.ACT_ID is not null
    and BRD_INAction.BRD_ID in (SELECT * FROM dbo.ADC_GetGroupBusinessRules('{GroupBPSID}'))
UNION ALL
SELECT
    'UseInAction' as Type,
    INact.ACT_ID AS ACT_ID,
    EnglishName as ActionType,
    INact.ACT_Name as ActionName,
    def.DEF_Name AS Process,
    app.APP_Name AS Application
FROM WFActions INact
LEFT JOIN Automations autm ON autm.AUTM_ID = INact.ACT_AUTMID
LEFT JOIN WFDefinitions def ON def.DEF_ID = autm.AUTM_DEFID
LEFT JOIN WFApplications app ON app.APP_ID = def.DEF_APPID
LEFT JOiN DicActionKinds on INact.ACT_ActionKindID = TypeID
WHERE
    INact.ACT_Configuration like '%{GroupBPSID}%'
UNION ALL
SELECT
    'UseInActivationAction' as Type,
    ActivationBRD.ACT_ID AS ACT_ID,
    EnglishName as ActionType,
    ActivationBRD.ACT_Name as ActionName,
    def.DEF_Name AS Process,
    app.APP_Name AS Application
FROM WFBusinessRuleDefinitions BRD_ActivationAction
LEFT JOIN WFActions ActivationBRD on ActivationBRD.ACT_ActivationBRDID = BRD_ActivationAction.BRD_ID
LEFT JOIN WFDefinitions def ON def.DEF_ID = BRD_ActivationAction.BRD_DEFID
LEFT JOIN WFApplications app ON app.APP_ID = def.DEF_APPID
LEFT JOIN DicActionKinds on ActivationBRD.ACT_ActionKindID = TypeID
WHERE
    ActivationBRD.ACT_ID is not null
    and BRD_ActivationAction.BRD_ID in (SELECT * FROM dbo.ADC_GetGroupBusinessRules('{GroupBPSID}'))

This query covers three situations:

• a group used in a business rule attached to an action,
• a group entered directly in an automation’s configuration,
• a group used in an action’s activation rule.

2. Group Used in a Form Field
 

SELECT
    WFCON_ID as FieldID,
    WFCON_Prompt as FieldPrompt,
    iif([WFCON_IsVisibleSqlBRDID] = BRD_Field.BRD_ID,1,0) as FieldVisible,
    iif([WFCON_EditModeSqlBRDID] = BRD_Field.BRD_ID,1,0) as FieldEditMode,
    iif([WFCON_IsRequiredSqlBRDID] = BRD_Field.BRD_ID,1,0) as FieldRequired,
    iif([WFCON_DefaultBRDID] = BRD_Field.BRD_ID,1,0) as FieldDefaultValue,
    def.DEF_Name AS Process,
    app.APP_Name AS Application
FROM WFBusinessRuleDefinitions BRD_Field
JOIN [WFConfigurations] ON [WFCON_IsVisibleSqlBRDID] = BRD_Field.BRD_ID
    or [WFCON_EditModeSqlBRDID] = BRD_Field.BRD_ID
    or [WFCON_IsRequiredSqlBRDID] = BRD_Field.BRD_ID
    or [WFCON_DefaultBRDID] = BRD_Field.BRD_ID
LEFT JOIN WFDefinitions def ON def.DEF_ID = BRD_Field.BRD_DEFID
LEFT JOIN WFApplications app ON app.APP_ID = def.DEF_APPID
WHERE BRD_Field.BRD_ID in (SELECT * FROM [dbo].[ADC_GetGroupBusinessRules] ('{GroupBPSID}'))

The query checks four field properties that can be controlled by a group-dependent business rule:

• visibility (Visible),
• editability (Edit mode),
• whether it’s required (Required),
• default value (Default).

This is one of the most common reasons behind the report I hear: “I can’t see this field, but my colleague can” — and it’s the hardest thing to trace manually, because it means going through every field’s configuration in the designer.

3. Group Used on a Transition Path
 

SELECT
DEF_Name as Process,
APP_Name as Application,
WF_Name as Workflows,
STP_Name as Step,
PATH_Name as PathName,
PATH_ID
FROM WFAvaiblePaths
JOIN WFSteps on PATH_STPID = STP_ID
JOIN WorkFlows on STP_WFID = WF_ID
JOIN WFDefinitions on WF_WFDEFID = DEF_ID
LEFT JOIN WFApplications app ON APP_ID = DEF_APPID
where PATH_AssignmentsBRDID in (SELECT * FROM [dbo].[ADC_GetGroupBusinessRules] ('{GroupBPSID}'))
    or PATH_AssignmentsDWBRDID in (SELECT * FROM [dbo].[ADC_GetGroupBusinessRules] ('{GroupBPSID}'))

Transition paths between steps can have executors assigned (PATH_AssignmentsBRDID) as well as “for your information” recipients (PATH_AssignmentsDWBRDID) based on a business rule. This query shows in which processes and at which steps a group is responsible for routing a task to specific people.

Limitations Worth Keeping in Mind

• This is not a complete map of every possible place a group can be used in WEBCON — it’s the set I encounter most often in practice.
• The ADC_GetGroupBusinessRules function is my own original solution, not part of the standard WEBCON API.

Summary

Permissions in WEBCON aren’t just WFSecurities and WFConfigurationSecurities, which I covered in the previous article. AD/Webcon groups live a life of their own in the system — as action executors, field visibility criteria, or conditions for transitions between steps. That’s a second, equally important dimension of the audit, one that’s easy to forget because it doesn’t show up on the standard permissions screens.

Without an audit like this, changing or deleting a group can be a gamble — you never know whether, somewhere in a process, it’s responsible for something whose effect you’ll only see once it stops working. These three queries, combined with the ADC_GetGroupBusinessRules function, let me check this deliberately, instead of relying on memory or luck.

As I mentioned earlier — this isn’t a closed list of every possible place a group can be used. It’s the set that works best for me in practice, and one I keep expanding whenever I run into a new case.