Steve Giller
-
Posts
6,467 -
Joined
-
Last visited
-
Days Won
267
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by Steve Giller
-
-
(I merged the double-post)
-
15 minutes ago, Sam P said:
Would I be right in saying that if the customer is removed after the Wait for Customer node is completed that it could proceed without one?
Reading around the question, you can lock access to the "Change Customer" action which will prevent the Customer being removed once assigned (apart from by a "Full Access" User)
-
@Stuart Torres-Catmur The Tool is designed to remove the emails from your Instance and provide them as files that you can retain locally without consuming Hornbill storage.
Once they are exported they are your files to process as you see fit, if you need to free-search the archives (either natively or via some sort of file-searching tool) this would be something you would need to investigate internally, Hornbill do not provide this.
-
There is no concept of "counting" in a Workflow, this would be most easily achieved by the Analyst using the "Copy Request" option, or with a Custom Button that duplicates the existing request from its details.
-
There's an action in place to improve the sorting on this that should appear shortly.
-
@JAquino Could you give some details, please?
I've just tested both setting and amending a Priority on my Instance and there were no issues.
-
4 hours ago, Giuseppe Iannacone said:
I'm unable to post an update on the timeline as customer
I very much doubt there will be a setting/API to say "This is the Customer" as that will be evident from the session context matching the Customer of the Request.
Are you asking because you've posted an update (in which case, what did you use?) and the Workflow did not move on?
I'm not sure what the correct one would be, but if it's the one I'm thinking of this is not publicly available.
-
This is the button you need, I think?
In my Instance there are 5 Services - I have favourited 2
-
Is the automated User the Customer of the Request?
-
Then the second scenario applies; while possible, this method is not practical.
-
The short version is:
Pull 6 months' data, store this in a table locally, or even a spreadsheet.
Pull the next 6 months' data, and then add that to the table/spreadsheet.
-
1
-
-
I'm not sure I understand the request, here.
A radio button presents a list of options and allows you to select exactly one - the initial request was about adding multiple teams so a radio button seems like the least suitable option.
If you're asking for a list of your Teams to select from, we have Customers with hundreds of teams to choose from and any kind of list would be completely unusable for them in this area.
-
I'm not sure what you're asking here?
API Key rules are generally required for things like Import Tools where a number of different APIs will be utilised by the Tool, and the Rules restrict the API Key to the required ones.
Raising a Request is simply calling an API - rules should not come into it here.
What you should be doing is establishing a session against a User who can Raise the Request (i.e. they would be able to do this via the UI) and raising the Request, then closing the session.
-
Unless I'm misunderstanding, I'm pretty sure you can do this ...
-
I've merged these two posts as they appear to be the same question.
-
On 17/04/2024 at 09:33, AlexOnTheHill said:
I think agents will always consider that any response is a first response
Being pedantic - this is a policy decision for each Organisation to make and agree with their stakeholders.
In my previous life, we determined that a "meaningful" response was required, and defined that as being a human interaction - phone call, face-to-face, or email but excluding any automated "Your request has been accepted/assigned" etc. interactions.
If I remember correctly we stipulated that any non-email first response had to be followed up with an email summarising the interaction so we had a concrete record (for other reasons than progressing the Request) but that meant we never faced the "whichever comes first" scenario.Based on your last reply, a Human Task with an "I responded via email/phone/visit/other" option would work, but I appreciate that might be viewed as an extra click by the analysts.
-
1
-
-
The most logical suggestion is to ensure the Line Manager is imported during your Azure Sync as detailed in the Documentation, and then the customer's Line Manager is already available to the Workflow.
-
@Giuseppe Iannacone As the error states, the search filter "value" field needs to be an array - it can be an array with one entry, but it must be an array.
-
On 12/02/2024 at 10:53, AlexOnTheHill said:
I have a team who would like to mark the response timer based on when an email is sent to the user
This is possible.
On 12/02/2024 at 10:53, AlexOnTheHill said:How am I able to suspend pending email or assignment, whichever is first?
This is not possible.
If you can identify whether an email is required or not within the Workflow, you can branch on that and have two separate (unconnected) Suspend nodes, but you cannot wait for "whichever comes first"
This is really about the Team requesting this defining how they decide whether an email is required and ensuring this is measurable by the Workflow. If they can't do that, they can't have the feature, unfortunately.
-
@Jim The short answer is, if it's not visible in the new documentation then it's not available for Customers to use.
A more detailed discussion is available here:
-
On 12/04/2024 at 14:12, Daniel Smith said:
I assumed that the BPM would follow the settings against the Catalog item that the switch capture uses
I'm confused by this part - a Switch Capture does exactly that - switches to a different Intelligent Capture. It is not a Switch CI node.
A CI uses a Capture, a Capture does not use a CI. -
This is not an issue that we have been able to reproduce.
On 03/04/2024 at 14:11, Caroline said:/apps/com.hornbill.servicemanager/flowcode/fc_modules/global_helper.js(316): error X1001: Uncaught EspMethodCall::invoke: Operation[admin::getApplicationList] The following rights [manageApplications] in Group D are needed to invoke the method admin::getApplicationList
is not in any way related to closing tickets, I would only expect to see this operation called in the Admin view, and if it was the cause of the User not closing the Request it would have appeared as a popup at the time.
Some information on how the Users are trying to close tickets, what happens when they do, any errors or other messages etc. would be useful here.
As a final note, the Super User role should not be applied to any User who uses the system on a day-to-day basis, this should be reserved for the System Administrator account (or a similar User) where it would only be required to access the system and reset settings if something catastrophic happens.
-
1 hour ago, ilyaas said:
System administrator so full admin rights.
I'm slightly confused here, there is no Role called "System Administrator" - there is a "Super User" role but this does not mean it ignores the Security model.
The default Admin User is called "System Administrator" but likewise this does not automatically mean it has access to everything on the system.
More importantly, neither the System Administrator User nor the "Super User" Role (if that's the role you meant) should be used for anything except recovering from a catastrophic issue - e.g. your SSO config has broken and System Administrator is the only User who can use Direct Login. -
What Roles does the User against whom the API was generated have?
Error Code 1 - Could not connect to Server
in Service Manager
Posted
Your Instance Healthcheck is showing all green, and none of our automated connection tests have flagged any issues for your Instance.
The issue in the linked post affected all users on every connection attempt for that Instance, and the underlying issue was permanently resolved, so this will not be related.
Can you confirm whether this is affecting all Users, a particular group (e.g. at a specific location, or remote workers only etc.) or does it seem random?
"Could not connect to Server" is normally (but not exclusively) literally correct and indicates an issue between you and Hornbill that is preventing a connection, so any additional information could assist our Cloud Team in trying to establish where the problem lies.