To get the filter to only show groups that share the same parent group as the assigned group should be straight forward.
Assuming the dropdown is on Incident (on my OOTB I'm using Suggested Assignment) create the filter with condition Parent Gruop = runtime value of CurrentAssignment/Group/Parent Group.
To limit the filter to certain process statuses add a fillter condition (on the Attribute Filter Selectors window, not on the filter itself!) of Status = 'whatever' and add multiple conditions for each status the filter should kick in. This should mean the filter won't be applied at other statuses and the dropdown will show all groups.
Oh having re-read your original post I see its the gruop to assign to you want to limit, this won't be able to look up other groups as the assignment isn't associated with the incident until it is saved.
Hoever if you use a dummy action before an automatic assignment with a window based on Incident you can use user/group relationships on Incident and then use the method in my first reply.
Cheers Stu and that is a great clue. I need to do this off a custom action, so I used the same technique as you suggested, but made the condition at runtime group on the customer action = incident/current assignment/... Actually it shows incident/current assignment/ ... but I'm guessing thats an artifact
However despite some iisreset and snapin.config deletions, it still lists all the groups.
Ah that'll be a problem then! The link from your collection object to incident (which is used in your criteria) does not get created until you hit Save. This limits what you can do with filters on collections so you'll need to do a dummy action from Incident with an automatic action for your custom collection after it.
Having to do this could also make it easier to limit the filters by status because you could have different actions/windows/attributes at different statuses.
Aha - all is clear! I have to say that this needing to save before a relationship can be used is a bit limiting. Windowless actions get round things for sure, but you soon clog up your incident object with attributes to copy. Architecturally when you're using a custom action, everything is there for the product to use and it goes ahead and let's you use it - it just doesn't work, unless you know a Stu who can point out these little wrinkles :-)
Still there you go.
Thanks once again Stu.
I know this post is years old, but given the amount of time I spent trying to figure this out and lack of info on this, maybe I can save someone else the trouble.
Like David, we have an IT department and a Facilities Dept on different incident processes, and I need to prevent the Facilities & IT guys from assigning tickets across departments. The problem is that the IT department is 4 seperate groups, so this keeps us from using the built in function to prevent analysts from assigning tickets outside their departments. The obvious solution is to setup parent groups for each, but then you run into the issues discussed ABOVE where the assignment window needing to be saved first so the needed fields for the filter don't populate yet. I tried to filter by window but the filter is global for some reason and effects new assignment windows so it was useless.
My Solution in English: We can't filter based on the ticket's old (really current) group parent-group, but we can filter based on the person (who is reassigning) primary group parent-group. Every child group (department) must have a parent, parent groups must not have analysts. So all child groups must be on the same level and all analysts must be on the same level under the children only.
Group field: Parent Group is equal to ( CreationUser/CurrentGroup/ParentGroup )
Keep in mind this is creationUser of the assignment action, not the ticket.
IT Road North
IT Road South
Analysts 1-8 can assign to other areas of IT, but not to the IT parent itself. This might be a problem for some people. Notice how facilities has no siblings, but has a parent.
If someone has an easier way I would love to hear it.