Workspace Workflow Automator not firing on Category change
Hi All - I’m working on a new FS instance and it has WS enabled by default.
I’d like to use a Global Supervisor Rule to change the Category on a new ticket from null to Software - this is working - then have a Global WF fire to send an email when it sees the change from null to Software - this is not working and I’m wondering if the different tiers are the problem.
OR is FS not accepting the change from null to software as “Ticket is updated” for the event condition.
AIM: I’m doing it this way bc Supv Rules do not allow me to send email to anyone other than Requester or Agent which is kind of a weird restriction.
Any assistance or other idea to achieve aim would be greatly appreciated.
TY Bryn
Page 1 / 1
Hello,
I think the issue here is that WFA do not trigger on changes made by the system. Why can’t you change the Category using a WFA?
TY @Daniel Söderlund - that’s what I was afraid of.
I wanted to send an email to a non-agent account to let me know an inbound ticket had been created.
Another loss by going to Workspaces, Supervisor Rules no longer allow you to assign the agent directly, you have to assign the ticket to an Agent Group and then let auto-ticket-assign take over - which seems very weird.
Supv Rule can’t be used to send me an email and I can’t assign the agent directly so I use it to send an acknowledgement email back to requester when someone emails us (rare but happens).
I don’t like using the canned “New Ticket Created” email notif bc we work with customers who have their own SAAS Help Desk and I use use Supv Rule to exclude autoreplies (ticket created, ticket closed etc) from triggering our automation.
Then I created a scheduled WF to fire once a day on every ticket that does not have a Category and then assign a Cat/SubCat/Item to prevent being re-sent on the following day.
TY @Daniel Söderlund - that’s what I was afraid of.
I wanted to send an email to a non-agent account to let me know an inbound ticket had been created.
Another loss by going to Workspaces, Supervisor Rules no longer allow you to assign the agent directly, you have to assign the ticket to an Agent Group and then let auto-ticket-assign take over - which seems very weird.
Supv Rule can’t be used to send me an email and I can’t assign the agent directly so I use it to send an acknowledgement email back to requester when someone emails us (rare but happens).
I don’t like using the canned “New Ticket Created” email notif bc we work with customers who have their own SAAS Help Desk and I use use Supv Rule to exclude autoreplies (ticket created, ticket closed etc) from triggering our automation.
Then I created a scheduled WF to fire once a day on every ticket that does not have a Category and then assign a Cat/SubCat/Item to prevent being re-sent on the following day.
Hmm, you used Supv Rule to assign a ticket after a specific time? You seen there are Global Supv Rules and one for the WS as well? You can only assign to agent when you are in WS admin.
I have setup a WFA to handle notifications. You use a condition node to verify the requester/e-mail(from or to) then you add this action.
Hi @Daniel Söderlund
Yes, ty I have looked at both Global and WS Supv Rules and I’ve chosen the Global so that all the WS we create will inherit the rule. I have the Global Supv Rule set to run as early as possible, Hours since created = 1 (Cal) so that at least every hour (on the :36 for my instance) any new inbound ticket with no Agent assigned will trigger this rule.
Yes, in my WF, I use condition node to confirm and then the Skip New email notifications as well.
Thanks,
Bryn
Hi @Daniel Söderlund
Yes, ty I have looked at both Global and WS Supv Rules and I’ve chosen the Global so that all the WS we create will inherit the rule. I have the Global Supv Rule set to run as early as possible, Hours since created = 1 (Cal) so that at least every hour (on the :36 for my instance) any new inbound ticket with no Agent assigned will trigger this rule.
Yes, in my WF, I use condition node to confirm and then the Skip New email notifications as well.
Thanks,
Bryn
Did you get a Global Supv Rule to assign a agent? When I checked there was only option for that to do in the WS Supv Rule.
Hi @Daniel Söderlund - sorry I missed your question!
Unfortunately, no. But now I’m wondering if this might be a bug?
There’s been a change to FS in the new environments, GLOBAL Supervisor Rules can no longer assign a specific Agent directly in the Action node of the Supv Rule.
You can only assign an Agent Group - so if you want a particular Agent to be assigned, you must limit membership in that Agent Group to that particular Agent. A big loss in functionality, IMHO.
If you assign an Agent Group with >1 Agents then FS will follow assignment priority.
However, I just noticed that if I go to the WS Supv Rules, the Assign Agent option **IS** available there.
This doesn’t make a lot of sense to me since Agents are at the GLOBAL tier and are granted permissions across the WS - shouldn’t we be able to assign tix at the GLOBAL tier like we can now?
hmmmm strange, right?
Bryn
Hi @Daniel Söderlund - sorry I missed your question!
Unfortunately, no. But now I’m wondering if this might be a bug?
There’s been a change to FS in the new environments, GLOBAL Supervisor Rules can no longer assign a specific Agent directly in the Action node of the Supv Rule.
You can only assign an Agent Group - so if you want a particular Agent to be assigned, you must limit membership in that Agent Group to that particular Agent. A big loss in functionality, IMHO.
If you assign an Agent Group with >1 Agents then FS will follow assignment priority.
However, I just noticed that if I go to the WS Supv Rules, the Assign Agent option **IS** available there.
This doesn’t make a lot of sense to me since Agents are at the GLOBAL tier and are granted permissions across the WS - shouldn’t we be able to assign tix at the GLOBAL tier like we can now?
hmmmm strange, right?
Bryn
Agent are managed globally but the access to the groups are on WS level as I understand it. So Global do not know in which group an agent is in.