So what is happening is when the ticket was entered, it was assigned to a wrong assignment group, some work has already been done, do it could be in the access state or scheduled state. When that group got the ticket, the realized it was not theirs and the intend is to assign it to the right assignment group and for the process to start over.

Which is when I want to configure that field so they are able to reassign the ticket, and when reassigned to the new assignment group for the ticket to switch back to the new state

Hi @Mitchell_Milo 

Thanks for update. So in this case, i will recommend to use the Flow only, but it will be more challenging reason begin

1. OOTB flow says, when a change rejected then change go back to new state but in this case even we are changing the assignment group , we need to add this in condition.

2. We need to cancel all generate approvals as well and send back to new.

3. if change in Assess state, i can say still okay but if change in schedule state, it will whole cycle need to repeat.

Also are you using assignment group some where in change approval as well, if no, then i will say don't send the change back, just make assignment group editable and proceed. 

so need to think about all this first mate, before we make changes.

I think the implemented process is really needed in such scenario, how came that team started working on CHG without knowing if it actually belongs to them. It's also question on "change management" who approved that change. 

We can keep it simple, to just ask team to transfer that CHG to correct team and learn some good practice.

Hi @Mitchell_Milo , 

You need check any ACL or client script written on assignment group field and remove the applied restriction. 

For state change, apply the BR[after update] on change_request table with all valid condition [on assignment group ] and change the state.

-Thanks,

AshishKM

@Mitchell_Milo , ACL should be there is in Place which is handling the Assignment group restriction , on the second point it is not technically good approach as your restricting the assignment group on good purpose 

on the Last point you can write before update BR and give condition as Assignment group changes and in the script you can set

current.state=1;// update correct backend value

Note : Its not an best practice to move if the change is already Approved or Under waiting for approval as this makes issue on Workflow and you could see weired issues

Regards,

Shyamkumar