Skip to main content
B
BF_1381190014-Alexandrite
14-Alexandrite
January 6, 2026
Question

Users able to Complete Change Task Despite No Longer Being in Assignee Group

  • January 6, 2026
  • 1 reply
  • 81 views

Version: Windchill 13.0

 

Use Case: It is possible to assign a change task in Windchill to a user group. This will result in the change task being displayed on the home page of each of the users in the group when it is time for the change task to be actioned. If at this stage a user is removed from the user group that the change task was assigned to, it seems that the change task still remains available in the "My Tasks" table on the homepage of the user who was removed from the group.


Description:

I would like Windchill to prevent users from being able to complete a workflow task if they are no longer a member of the group that the workflow task was originally assigned to. Does anybody know if this is possible?

1 reply

avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
January 7, 2026

I think its certainly possible but the how is the key question. Are you looking for this to be something fundamental, common to any situation where a group.role is being used as participant? I think in practice, the group is used as a look up, at time of assignment, the tasks are assigned to the members but not tied anymore to the group (just for processing). What you might be looking for is two fold, a refresh action which updates based on the current group membership and a fail safe to prevent task completion if they are not part of the group.

 

The latter might be accomplished by adding some code to the task transition. This would mean its workflow and task specific. But, its less of a customization and configurable. You control when this rule is implemented and where. Its a double check. If the user has a task but is not part of the group, throw an exception to block it. Also would stop re-assignments of tasks. 

 

A listener on group updates could go through and remove tasks from uses who are no longer part of the group being updated. That could prevent them from even having to check for remaining tasks but you still have the case of task  re-assignment and delegation. 

B
BF_1381190014-AlexandriteAuthor
14-Alexandrite
January 8, 2026

Thanks for getting in touch @avillanueva.

 

I think the answer to your first question is yes. Whenever a group/role is being used as a participant, the ability of members of the group/role to make changes to objects/influence a workflow as a result of once being a member of a group should be revoked as soon as they are removed from the group.

 

The behavior you have mentioned seems accurate. It seems Windchill uses the group as a lookup and doesn't "tie" tasks to the group. But, I think I would rather see the tasks tied to the group and not the individual members of the group at the time the change task is issued. The behavior that I'm seeing in Windchill seems odd. Windchill provides the ability to to assign a task to a group. However, user groups are fluid since members of staff in enterprises and their roles within the business is constantly changing. As far as I've seen, the OOTB behavior I'm seeing in Windchill doesn't easily allow for the update in users ability to act on certain objects dependent upon their group membership status.  

 

The listener certainly sounds good. Being able to configure Windchill to remove tasks from a users workspace when they are no longer a member of the group that the task was assigned to would be great. You make a good point though - in the event that a change task has only been assigned to one person (as a result of them being the only member in the group that the change task was assigned to), and that user is then removed from that group, the system should throw an exception to make it clear that the task is now assigned to a group that contains no users who can ultimately complete it.

avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
January 8, 2026

I use roles mainly, derived from the Context Team (like a Product Team page). These are populated to the change object upon creation and are good enough for most cases. I do not often change Team members, but when I do, I make sure to utlize the replace team member which should update active objects and tasks (then take a sip of Dos Equis). I also have a step in workflows when things loop back around to "re-team" the change object. This refreshes the team with current members automatically. 

Terms & ConditionsCookie settingsAccessibility statement