Currently it isn't possible to use an automation to convert an incident to a service request based on Keyword, Cat, Subcat, etc. Would be very nice to have this ability within Automations.
With the changes coming to the maximum length of time certificates can be valid, it would be awesome if there was a way to automate this replacement. While it will still be manageable for the next few years, it will eventually be untenable to do it manually for all the different certificates we have to manage in IT . We've…
Please allow service task users to comment and update the task completion progress as a percentage of the assigned task via the service portal. The Incident owner or other responsible parties should be able to see the progress. This will help service task users to communicate with the requestor or the incident owner.
As an ITSM administrator, I want to add a configurable third-level (tertiary) dynamic field associated with Category/Subcategory so that I can better classify tickets, improve routing accuracy, and enable more flexible reporting without hardcoding additional subcategories. SWSD’s current Category → Subcategory model is too…
Due to the limitations regarding split form input in a Service Request, provide the ability pre-fill Service Request field data with URL parameters. For instance, for a given service request URL if ?field1name=field1value&field2name=field2value is appended, those matching fields would autofill that content.
I'd love to be able to automatically add a comment to a ticket with out having to use a API call as API calls are limited and do not allow for HTML formating of the comment. So I propose that the Global Response Templates be available to be used as an Action in the Automation Editor. (or even in Runbooks or Service Catalog…
I'd love to have Runbooks available to be added to Service Catalog items Ideally the ability to nest them with in the Catalogs process as well as in parallel and one after the other.
Ability to see in the audit who unmasked data on a ticket. Useful for tracking who was exposed to sensitive data.
As an admin or service desk user, if you create an incident it will default the assign to as yourself. Most times we would like this to stay blank, and get assigned via our normal incident allocation process. If we want to assign it to ourselves, we could populate it, but by default we would like to leave it blank.
It would be a really helpful permissions restriction to be able to limit Agent user ability to see private comments if they are the requester of the incident. Private comments are often used by the Assignee for "off the record" conversations with managers or other agents to gather information or for approvals that don't…
It looks like you're new here. Sign in or register to get started.