Varying available statuses by group, for the same object

[GeraintJo]

I can't work out how to show different statuses to different groups for the same object - eg a project.

As a project moves through different stages, we want to allow different user groups to be able to change the status - but only to statuses visible to that group.

eg - to trigger an action in FUSION - that only that group can decide is appropriate.

All I can find is that groups can be assigned to an object - and then the statuses available to that group will be available.

Which means once I've assigned a project to a group - the statuses will apply to all groups seeing that project.

This seems VERY restrictive.

Has anyone managed to do something similar ?

maybe FUSION changing the group assigned to the project as it progress through the stages ?

Thanks in advance as always

[Kurt_Jones]

Geraint,

I think you've already started on your way to a solution.  In Setup->Project Preferences->Status you can set up unique statuses for each of your groups.  Those groups will only see those project statuses you allow them to see when they look at a project (as long as your admin has allowed subgroup statuses to be setup).  The part to think through would be what in the process triggers then next group and status to be notified to do their part?  What will trigger the next team and status to change, is it a certain task or getting to a certain milestone stage, as example?

[GeraintJo]

Thanks Kurt,

So you agree the only way to make this happen is changing the groups associated with the Project  as it passes thru the various lifecycle stages of the project ?

And if you want more than 1 sub-group to see the statuses ... - doesn't sound like that's possible without them both being in their own 'parent' group.

But this soon becomes unworkable !

And if you want different sub-groups to see different statues to use on a project when it is in a given status (in work etc)  - that's not possible either !

Overall - not the most flexibility !!

[Kurt_Jones]

Geraint,

Yea, the group statuses looks to be the workaround but agree it could make things a little wonky. I had an example in my head to put below, trying to think this through...is it what you're trying for?

So as example, we have project 1 in status Current (all groups can see this status).  project 1 has all tasks complete for milestone One and Fusion job is triggered to notify group Rock to view project 1 and update status to We Rock once their review is done.  You have to equate a custom status to one of the defaults, so We Rock equates to Current.  The project 1 is now set to We Rock, if you're in group Rock that is the status you see, if you're any other group with access you see Current.  With the review done by group Rock and status set to We Rock another Fusion job runs and notifies group Kick to view project 1 and update the status to Kick It once their review is done....and so on, and so forth as previously noted above.

[GeraintJo]

Hi,

yes that's in Kurt.

With FUSION changing the status associated with the PROJECT as it moves between the milestones.

There seems a lot of status flexibility by group, but limitation sin how it can be leveraged.

Thanks for your time on this.

[AmyReilly]

@GeraintJo @Kurt_Jones ,

Would Business Rules help with this use case?  (We don't have the package level with business rules, so I can't test on my side unfortunately.)  I believe you could give an error message if a group tries to change to a status that you don't want them to use.

[Kurt_Jones]

Amy, 

We do have business rules and use it for several things.  You're correct that you could narrow down actions on objects such as create or edit, such as status of a project (changes) and group ID (equals XXXX) then display a message, which may work for this use case, however, I believe Geraint may have many different groups, with many different statuses that need to do checks, so there is contemplation on whether this is if a doable ask based on the amount of work it might take.  🤔  Seems to always be the case with our users.