Restrict list of participants for a workflow task to users under a role?

[rdanner]

Does any one know how to limit the participant choices for a workflow task to only those members listed under a role in a product or library container? I know this can be done as I see it done in the "Change Request workflow" where the participants for the task is limited to only those under the "Change Admin I" of the context. I try to do this in my workflow, copying I think every attribute of the "Change Request workflow" into mine to make it just like the CR workflow and it just does not work. It allows me to select anyone in the context - not just those under the role.

I am on Windchill 9.1, m050

Any help would be appreciated as this is very frustrating.

[JamesBaile · Accepted solution]

Do you have a defined list of participants? or does it change by what is being promoted?

9.1 M060 and we use a custom promotion request process here

[rdanner]

James, thanks for the reply.

It is a defined list of participants under the "Promotion Approvers" role in the context. I have a preceeding workflow task to "select participants", I want that selection list restricted to just those under the "Promotion Approvers" role.

You second question: "or does it change by what is being promoted?" is very interesting. Is that possbile?

[MikeLockwood]

In general, yes you can branch a workflow based on what is being promoted. Example: If a label is included, Marketiing has to approve.

But - In general the system does not know what is a label or whatever - unless you use different sub types or fill in attributes with this info.

Branching can be accomplished in the workflow by using workflow variables - and these can be mapped to Object attributes or by sub type (e.g. a Document for a Label which has an attribute set to "label" can be mapped to the workflow variable "document_business_purpose"). Given this, a conditional in the workflow can be used to branch to include Marketing.

All this is relatively advanced but very useful workflow functionality - it's one of the areas that the investment in using Windchill can really pay off. Somebody definitely should write a book about all this (I may still do that one of these days).

[MikeLockwood]

In each workflow Activity in the template, you choose where to obtain the people / groups to fill the Role. If you want to use the context team, need to

a) set up a team template that includes the Role but no people

b) configure the workflow Activity to point to it

c) populate that Role in the context

[rdanner]

Mike, thanks for your reply, and I looked at your other postings and it seems you have a good understanding of workflow. Sorry to say I do not.

on item B) configure the workflow activity to point to it - How? List it as the role resource or point to it to resolve roles at runtime for the activity?

[MikeLockwood]

In the Workflow template, select the Activity, then select the Participants tab. You can select Roles, Groups, Users, etc. You can map these in various ways (e.g. the Approve Role is the Engineering Group). But also look at the last 2 tabs - these determine where people can be obtained for each Role.

Need to play with these a bit. The main objective is to have a workflow at Site or Org level mapped to a Role, then have the system find the users for that Role in the current Product (or Lib). So for example, the same Approver Role could resolve to Joe in Product 1, but to Sam in Product 2. This is very powerful and far-reaching and worth really getting to a point of full understanding.

If you like, I can show you on a webex.