Why am I getting "The value 'CSDESKTESTER1' does not exist for the field 'project'." error?

[Sara Nicholson]

I have a test project and I created an automation rule using the exact same steps we have in another project and just substituted the "project = (name of the test project)" in place of the current project. The automation works perfectly in our "active" project where customers submit tickets, however in my test project the automation keeps throwing an error that says "The value 'CSDESKTESTER1' does not exist for the field 'project'." 

I think it has to do with permissions, however, the permissions schema I am using is the exact same one for both projects. Can anyone help me resolve the issue? 

Thanks!
Sar

[Tom Lister · Accepted solution]

Hi @Sara Nicholson 

Even though the permission schemes are the same, do you have the same roles in both projects?

[Sara Nicholson]

Hi @Tom Lister , yes, I just double-checked doing a side-by-side of both project permissions and then my roles in each and everything matches up. 

Sara

[Tom Lister]

asking the dumb question -

Is CSDESKTESTER1 the correct key?
Can you run 'project in (CSDESKTESTER1)' in the issue navigator?
Is the automation actor you?

[Sara Nicholson]

Hi @Tom Lister , I have tried 'project in (CSDESKTESTER1), which is the project name. I have also tried 'project in (CSTESTONE)' which is the project key and both failed. Our "active" project where the automation rule is working as expected, uses 'project in (CS Service Desk).' 

The automation actor is not me, it is a separate Jira user a Jira contractor created that did all of our original setup. I am self-taught so I apologize for maybe not understanding everything you might ask but I SO appreciate the help! Do you think I should change the rule 'actor' to myself and see if that resolves the issue? 

[Sara Nicholson]

[Tom Lister]

It may well be that Client Support user has not been added to the project you are trying to access.

Try it with you as the actor. If that works.

Get the Client Support user added to the project and try again with that as actor again.

Using a dedicated user for automation is a good idea as stuff breaks when a real user leaves the organisation

[Sara Nicholson]

Just for some background so you know what I am trying to accomplish.... I have re-written our entire workflow for service desk because our development team just re-wrote ALL of their workflow (a complete revamp) and of course our service desk project has probably 50 automation rules in place (i.e., when a development ticket goes to a specific status the system updates the service desk ticket with the same status, etc.). We have a test environment but it is currently down and a complete copy causes issues with our prod site. So, I am using a test project with my new workflow (which manually works great) and I am one-by-one going through the automation's to apply them to the new workflow (with the new statuses, etc.). It is a tedious process and of course, this is only the second automation I've worked on (the first one worked) and it isn't working... 

So, I just saw your message to try myself as the actor and looked back at the 1st automation rule and it was successful in auto assigning me when I transitioned from Priority Set to In progress and the actor is clientsupport :( 

I really don't know how that is possible because I checked the users' roles and they are not assigned any in the CSDESKTESTER1 project... here are mine vs. the client support actor: 

ACTUALLY scratch that... I was looking at the wrong ticket... it did not auto assign me... I am changing the actor to myself and also adding the client support user to the project with my same permissions.... brb. :)

[Sara Nicholson]

OMG! I could cry right now I'm so happy :D :D That worked! I have the designated actor in the project with the correct permissions and I just ran both of my automation's and they both worked! THANK YOU THANK YOU THANK YOU!! I think I can safely move forward with all of my automation's now... but seriously if I run into any more issues I will come back if you don't mind :)

Again, thank you SO MUCH!

Sara

[Sara Nicholson]

@Tom Lister you were so helpful before I am wondering if you can answer another related question. I am creating some automation rules (exactly like the ones in our current project just using the testing project name and the updated statuses) in my test project and some are not working.

My workflow is set up so that (in most cases) the agent has to put the ticket into the "In Progress" status before they can set a new status (we do this because we want to record the time in progress and we have a pop-up screen when leaving in progress that requires the agents to record their time on the ticket).

The automation rules are such that when a linked dev ticket status changes (we have a specific field we reference), the automation will update the linked service desk ticket to the same status. This means that the workflow of going to "in progress" first is bypassed and the automation can go from any status to whatever the dev ticket status is with a few exceptions (i.e., if the service desk ticket is in To Do, Waiting on Customer, etc. - there are certain statuses that need to be excluded).  

Here is the automation rule I have set up. I have tried it many different ways and it is just not working. I wonder if it is because my workflow doesn't allow the status changes I am trying to do through automation? Any insight you may have would be appreciated... or anyone else in the community of course! 

[Tom Lister]

Hi @Sara Nicholson 

Off line today

check the user permissions

check the workflows support what you want to do

issue type workflow issue mapping is linked to expected workflow

[Tom Lister]

What is difference between status != closed and staus not in(blah)

[Sara Nicholson]

Hi @Tom Lister ,

Thanks for responding - sorry to bother you on your offline day... I will do as you suggested. The contractor we used to set up our service desk automation originally set them up that way... it didn't make sense to me either so I tried including Closed in my () and removed it from != but that didn't change anything.... 

[Sara Nicholson]

So, if my workflow doesn't allow any status to transition to another status (because service desk statuses can only go to In Progress in the workflow) I won't be able to use the automation if the service desk ticket isn't in In Progress.... Is that a correct assumption? And if that is correct can I add an action that puts it in In progress first and then moves it to the matching dev ticket status? 

Don't take time out of your day to answer unless you want to... I will keep trying and testing :) 

Sara

[Tom Lister]

Hi @Sara Nicholson 

I’ll look tomorrow

the overarching rule will be the automation actor cannot do anything not allowed by their permissions or the target workflow paths

[Tom Lister]

Hi @Sara Nicholson 

Did you get anywhere with your automation?

[Sara Nicholson]

Hi @Tom Lister 

Unfortunately, I wasn't successful in finding any solution to make my new workflow work as I want it to. Here is what my new workflow looks like (yes a lot of steps/statuses):

I allowed all statuses to go to "In Progress" but didn't let any of the other statuses go to each other (with one exception i.e., done which is used for a specific purpose). The other 3 statuses that you see "All" next to were just added yesterday based on how I think I will have to do the workflow (see more below). 

My goals were: 

1. Force Agents to always put a ticket into "In Progress" when they begin working on it
2. When they leave "In Progress" they can move to any status but must be required to add a comment and log time (I have a Log Work screen created for this purpose and it pops up as expected). 

My thought is that I will have to allow all dev statuses to go between each other (Allow all statuses to go to x status) so the automation's will work. Then I will need to put a validator on each transition that goes from "In Progress" to each status, requiring the comment/log work. I won't be able to "force" the agents to move a ticket to "In Progress" before they begin working on it. That's a training issue we have struggled with... 

Unless you have any other ideas that may work? I was hoping there would be a way in the automation to override the inability in the workflow to go in and out of all statuses but I don't think that is possible. 

Thanks so much for taking the time to look.

Sara

[Tom Lister]

Wow that is a big workflow - let me know if you want a separate conversation about what is going on there and options for complex workflows.

Some tips for debugging automation:

You can add audit log components in between the steps to validate where it is getting to and log relevant variables.

Does your JQL return expected results when run stand alone. If it returns no data, automation will accept that as correct and not continue the steps. ( does it contain all the statuses you need). 

Could you put " != closed" in the NOT IN list? that would mean the same thing I think.

If you know which ticket the automation is likely to move, confirm you can do that manually.

[Sara Nicholson]

It is a big workflow... I would be able to do a screen share call and can send an invite if you have time. Just let me know the date/time and I will send it. Might be easier :) 

[John Funk]

Hi Sara,

I would change it to a single project for that project and see what happens. 

Also, the Actor is Client Support - what does that represent? 

[Garrett McCreery]

Hi @Sara Nicholson 

Can you share your Audit Log?

[Sara Nicholson]

Hi @Garrett McCreery , here is a screenshot of the error, does this help? Or, is there somewhere I can pull the log report? Sorry haven't been asked that before :) 

[Sara Nicholson]

I'm also unsure why the date shows 01/06/22? 

[Garrett McCreery]

European date format. DD/MM/YY

[Garrett McCreery]

In your screen shot I am confused by your JQL. The project that is firing this off is INFR, but you are trying to query items in project CSDESKTESTER1. Can you explain that?

[Sara Nicholson]

Hi @Garrett McCreery , Thank you for your input... I was able to resolve my issue above... and yes the INFR project actually fires off the automation... a change to the "Done" status in that project causes the status on the service desk ticket to update to the Done status as well. Sorry for the confusion! :)

Sara

[Garrett McCreery]

No worries, I'm glad that @Tom Lister  was able to help!