Hi.

Do you actually mean to create a task within the SR for someone to handle it?

Ans) If this is the case, yes, you may, and even automate it; this could be a starting point:

Or, do you mean for a process to be run when that occurs?

Ans) Yes, this is also possible, and this may be a good starting point:

If your inquiry is related to something else, would you mind elaborating it?

Hope this helps.

Regards,

Elvis

Hi Elvis,

Thank you for your reply.

I meant this for a process to be run after the SR ticket is closed.
So when the condition for the ticket is "closed" an action is trigged to automaticly clear some custom fields with sensitive data in the ticket.

Regards,
Douglas

Hi. Then, the second given option sounds like the one for your use case. Or you mean some time after the ticket is closed? If this is the case, you may want to create a Supervisor Rule for that with the same logic.

Regards,

Forth option are a app 

I am pretty sure that workflows will not run on a closed status from an event basis because the volume would be huge when it runs. I would write a script or custom app that does this. If you dont have JavaScript capabilities you could setup an automatic export via analytics that kicks out a CSV file containing the ticket numbers that have the fields you are looking for.

From there you’d grab the ticket numbers and run a foreach against them that sets the value to null via an API call.  Depending on your volume of tickets, you’d want to build in some error handling. I did something similar when we migrated every resolved/closed ticket in our system that had a field with “resolution information” to use the new resolution notes field but that was a one time deal.

Ya, if you can clear when status is change from resolved to closed. After that you need a script as you say. 

Ah Ok, Thanks.

If the ticket status is "resolved", can you do this without a script or app?
Can we just use FS built-in API to clear data in custom fields in the ticket?

You can use the API to edit the field(s) when it goes to a resolved status but know that if the ticket gets reopened that data is going to be gone and would have to be asked for again from the requester.

Additionally, since each field is going to have a unique number on it tied to the service item it sits on, you’d have to build a condition for every single service item then do a uniquely setup API hit so that you are hitting the right field. It doesnt look like the reader table functionality would support having a list of each Service item and then entering the field there to reduce your automation complexity.