Victor
-
Posts
5,696 -
Joined
-
Last visited
-
Days Won
169
Content Type
Profiles
Forums
Enhancement Requests
Posts posted by Victor
-
-
17 minutes ago, Berto2002 said:
Will you be publishing the cause?
@Berto2002 certainly will, just need to make sure we have all the bits and pieces beforehand.
-
In terms of the issue itself, we do have a decent idea of how it came to be, the what's and why's. However, we would like to investigate this a bit further, in bit more detail, before we come back with a more in depth RCA. I will update the thread when this is ready.
-
@KrisReynolds there is no "resend all" button I'm afraid. Each email has to be resent, as suggested by Martyn.
-
We have deployed a patch in all live instances that should address the issue with outgoing email. Emails that failed to be send while the issue was ongoing and currently residing in Sent Items folder can be manually resent. Emails that failed to be send while the issue was ongoing and currently residing in Outbox folder will be automatically sent on the next attempt.
-
We are almost ready to have the fix deployed. Current ETA is to have the fix deployed by 15.00. I will update this post if anything changes.
-
3
-
-
We identified the root cause for the issue and we are working to deploy a change that should resolve the issue (this is currently being tested). We will post more details about this shortly.
-
We have received information from Microsoft regarding recent changes whereby they have disabled TLS 1.0 and TLS 1.1 on SMTP connectors. However, we are not affected by this particular change as Hornbill already supports TLS up to 1.3. We are continuing to investigate the issue and possible options here.
-
@Berto2002 thank you for the update, happy to hear the Direct Outbound solution is suitable and working for you.
-
9 minutes ago, Martyn Houghton said:
Switching over the Direct Outbound will require a DNS entry
@Martyn Houghton yes, we know... it is a proposed solution, might not be suitable for some... we are definitely looking into finding more alternative solutions (if there are any) as well as any possible code changes we can implement here. I assure everyone this being investigated internally with the highest urgency and priority.
To clarify for anyone else, Direct Outbound requires an SPF record (which is in essence a DNS entry/record). More info here: https://wiki.hornbill.com/index.php?title=Outbound_Mail_Routing -
@Oscar Stankard thank you for the update, happy to hear the Direct Outbound solution is suitable and working for you.
-
@Berto2002 it is possible the authorisation email fails to be sent due to the issue(s) discussed here:
-
It is not very unusual for Microsoft to not have posted an update in this regard. We have raised the issue with Microsoft and we are looking into any possible alternatives and solutions that can be implemented on Hornbill side in the interim to restore the service functionality.
-
1
-
-
@samwoo short answer is no, not really, but would be good if we can find some details as to what this CRM system would be used for in your organisation (apart from the obvious acronym) ...
-
@billster nice
what was it?
-
@Stefania Tarantino running workflows(*) will be displayed in this list, which is the intended purpose here. This allows any Hornbill administrator to review running workflows or failed ones for example to identify issues, potential gaps, blockers, etc for any workflow configuration. We would not want to empty this list, if we do that, Hornbill admins or BP designers will have no access to running workflows and in your case, you will not be able to access any (old) suspended workflow to identify why they are suspended and correct and optimised this in future configurations. Why would you say it would be a good practice to empty this list? I am trying to understand this because emptying this list as the term implies, would only remove them from view, any problematic workflow will still exist in an instance but now you will not know about nor you will have access to it.
*we define a running workflow as any workflow that is not completed, failed or cancelled (this means a suspended workflow is a running workflow aka not completed) -
13 minutes ago, Stefania Tarantino said:
The extra work being caused goes back to my comments in the below post about the number of indefinitely suspended workflows which have accumulated and need analysing to understand the reason they are suspended.
I understand, but I don't see how the product has caused extra work? The workflows have been configured to be suspended indefinitely and they have, I don't see any fault here...
13 minutes ago, Stefania Tarantino said:Surely good housekeeping practice dictates that these workflows should be cleared out, rather than simply left there?
Sorry, I am not sure what you mean here... workflows left where?
13 minutes ago, Stefania Tarantino said:Also as per my earlier comments we need to resolve the issue of automated actions in the later stages of the BPM not being completed and ensure our reporting is accurate.
13 minutes ago, Stefania Tarantino said:I think our process needs changing but I am not sure of the best way of doing this.
You can reach out to customer success, I am certain they can arrange a session with our product specialists to review your current configuration and problematic areas that you noticed.
-
@QEHNick rights are only visible on roles... you can think of roles as a collection of rights... so, for example, Incident Management Full Access
-
@Stefania Tarantino I think the keyword here is can... the request and workflow can (and at many staged they do) work independently. Obviously this does not mean that a request and it's associated workflow are completely independent... only means that they can be, or better said can perform actions independently, at various points in their lifetimes.
I'll try and make this more clear with two examples:
First example: we have, let's say, a very simple basic scenario. An alert email creates a request. This request will always be assigned to team A user X, will have the category NNN and will email user or contact Y something. Nothing more, this how that particular service desk operates for this scenario. Here, you can have the workflow automate some actions so user X does not have to perform them manually. The workflow here will initiate at the same time as the request (this is always like this). The workflow then will assign the request, set the category and send the email and then it will end (complete). All this time the workflow performed these actions there was no manual action on the request. There wasn't any analyst to perform an update, set a priority or otherwise action on that request in any shape or form. You might also notice in this scenario that once the workflow completes, the request is very much active. It's still in a "new" state, still appears in user X queue. At this point user X can perform other actions on the request, for example, set a priority, send another email to a possible interested party. Can resolve and close the request. All these actions performed by user X happened outside the workflow, they happened while the workflow was completed thus having no influence in any shape or form on the request. From all this perspective we can say that the workflow acted independently from the request (when it assigned categorised and emailed) and the request acted independently from the workflow (when it was prioritised resolved and closed).
Second example: we now have a more common scenario, which is a, let's say, "classic" auto closure sequence. You have a request with an associated workflow. Upon closing the request, the service desk will wait for customer feedback for 2 working days. If the customer feedback is received within the timeframe, depending on the feedback the request reopened. If no feedback is received after 2 days, an email is sent to customer as a reminder for feedback then the service desk will wait for customer feedback for another 2 working days. If the customer feedback is received within the new timeframe, depending on the feedback the request can be reopened. If no feedback is received after these other 2 days, no further actions are taken. Here you can have the workflow automate this sequence so the user/analyst does not have to specifically monitor, chase and progress the respective request based on the feedback. Initially, in the early stages, you can have the request and workflow doing a number of things. And then, upon closure (when the request is closed) you can have the workflow perform the auto-closure sequence (wait for feedback - with expiry perhaps, when not ok feedback is received, reopen the request, when feedback expired, send email reminder and repeat from wait for feedback). You can see here that once the request is closed, the workflow is very much active and will perform a number of things. The analyst does not interact with the request anymore (unless is reopened) and assuming that ok feedback is received or no feedback is received, the workflow will wait and chase completely independent from the request, there is no other activity on this request since closure.
I hope this clarifies a bit in what way and how requests and workflow can (and many times will) perform actions independently. In most scenarios, the request and it's workflow have many touching points, they often interact with each other and, if one desires, they can be configured to work and behave in perfect sync, although this is not really practical and not the true purpose of a business process.
3 hours ago, Stefania Tarantino said:Something which is causing us extra workload.
I would like to know more in what way the suspend nodes are causing you extra work? Can you detail on this please?
3 hours ago, Stefania Tarantino said:I am not really sure what the max loop count is - I assumed that this is the max number of times a process is checked eg for if a category has been set yet.
Max loop count is a mechanism when you have a loop set in your workflow. Loops work with decision nodes where you have a decision branch connecting to a node prior to the decision. An example of a loop would be in the auto-closure sequence I described above where after the email reminder the workflow "loops back" to waiting for customer feedback. Max loop count specifies how many times a workflow can loop in a sequence, which is 1000.
Suspend nodes don't work with loops, there is no loop mechanism here, they are event based. This is where an even triggers an action, for the category example, the event/trigger is the analyst setting the category which resumes the workflow or the event/trigger can be the node expiry (if configured) which also would resume the workflow.
-
1
-
-
2 minutes ago, Stefania Tarantino said:
What I would like is for the category to be set before the incident is progressed. I am expecting that if the category is not set the incident will not be able to be resolved or closed given that we have a lock resolve action node in place in the BPM.
There are ways to achieve this but I need to clarify that there is no specific built-in functionality to prevent closing a request without a category. Another thing to clarify is that workflows are requests are two independent entities that can do things and progress independently of each other. They can of course interact and they can be designed to interact but in essence, they are separate entities with their own paths and lifetimes. This means that, for example, a request can be manually closed by an analyst while the workflow does something completely different or simply is suspended at some point that has nothing to do with a request closure. This is an important aspect to keep in mind when designing workflows.
If you want (to enforce) the category to be set on a request before is closed, one approach is locking actions. You can have the workflow lock the Resolve action and unlock it once the category has been provided. As you noticed, there are SM roles that can override the lock so analysts need to have the appropriate roles and rights for this to work. Also, you would need to ensure the request cannot be closed by another means, such as auto tasks which can run from custom buttons.
12 minutes ago, Stefania Tarantino said:However we are still seeing incidents being resolved/closed without a category.
If you have all the right configs in place, then this might be an issue that we should investigate, so if that's the case raise a support request with us.
What about the "max count loop"? This has nothing to do with suspend nodes so I wanted to clarify this as well, if needed.
-
@billster there are two set of rules that would need to be configured here;
- one set to determine what SLA (Service Level Agreement) will be set on the request - these are the rules configured when you associate (corporate or service) SLAs to a service
- one set to determine what SL (Service Level) will be set on the request for the above SLA - these are the rules configured when you design the SLA on the SLA itself
Perhaps there is a misconfiguration between the two or one set is done but not the other?
-
19 minutes ago, Stefania Tarantino said:
The owner and priority suspend nodes seem to be working as expected.
The suspend wait for category node seems to have caused many of our workflows to be suspended indefinitely.
Does this mean that in your view, the Wait For Category node does not work as expected? What is your expectation in regards to this node?
19 minutes ago, Stefania Tarantino said:There is no expiry set on the suspend wait for category - but the suspend wait for priority node which works does not have an expiry set
Would these be the problem? Should these options be set in the BPM?
What would be the problem? Is that the workflows should have progressed to completion? If yes, then this is what @Steve Giller advised above, the workflow will suspend until the category is set on the request. If the node is not set with an expiry period then it will wait indefinitely, until the category is set. As to if the node should be configured with an expiry, it entirely depends on how you want/need it to work... if it should not wait indefinitely then set up an expiry that will progress the workflow automatically when the threshold is reached.
19 minutes ago, Stefania Tarantino said:If a manual action - ie adding a category - is not taking place what happens to the suspend node?
As per above, the workflow will be suspended at this node indefinitely. Only setting the category will resume the workflow, no other action will do this.
19 minutes ago, Stefania Tarantino said:My understanding is that there is a max count loop of 1000 set on workflows. What happens when this is reached?
What is your understanding of "max count loop"? I think there is some confusion here in regards to "max count loop" and the suspend node...
-
On 11/16/2022 at 4:30 PM, Berto2002 said:
that recalculates the whole SLA from scratch which means it nullifies any previously captured values like the start or end of a response or resolution timer
@Berto2002 not quite, I'm afraid. There is a recalculation but it does not nullify anything like start and end of response timers. This is a case of APIs that need to execute in a specific sequence, will sometime queue up in a slightly different order, which is sufficient to lead to issues like timers not being marked or incorrect timer values.
-
1
-
-
I know this is not answering the question about roles and such but
2 minutes ago, AlexOnTheHill said:request logged to team A also has an activity assigned to it for completion by team A and when assigning to team B that request cannot be closed without team A completing it
Isn't this more of a problem whereby Team A assigns the request before completing a task assigned to the team? Why is the task not completed before reassigning? There could be a very valid reason here, I am just trying to see what that is...
-
There are two type of subscriptions in Hornbill, platform subscriptions and application subscriptions. The full users you are referring too are platform users. In order for any of these users to have access to application functionality (e.g. Service Manager app) they need an application subscription (e.g. Service Manager subscription). Not all users need an application subscription only the ones that need to use application functionality.
Users that appear in the list in Service Manager section (screenshot) are users that have been allocated an application subscription (Service Manager). If you remove a user from this list, the application subscription assigned to that user and it will also un-assign all the application roles the user has allocated.
So any app user is a full user but, not all full users are also app users (meaning some full users are not app users).
-
1
-
Afterhours SLA
in Service Manager
Posted
@billster yes it is possible, but not just with the SLA, we need to get the workflow involved here... the workflow, specifically the SM "Get Request Details" node, has a very useful variable for this scenario: time logged. This is a number representing the seconds that passed since midnight. As you can probably imagine, we can use this to determine if the request was raised OOH or not. Then we can branch the workflow and, let's say we assign a certain priority in both cases. We can then set SLA rules based on this priority. Or, alternatively, use request custom fields and set SLA rules based on values in that field. Makes sense?