James Ainsworth

Just to confirm that the workflow instances do count toward the data quota. The question from here possibly turns to value and if there is value in maintaining the workflow tracker at the top of the request for historical reasons vs saving some space.

I know that the list of main Workflows is counted toward data usage. I have asked the question if workflow instances are included. The documentation here: https://docs.hornbill.com/hornbill-cloud/data-storage simply says "Business Processes" so I wanted to clarify what that includes. I also don't know what the implications of deleting a workflow instance. This will remove the workflow tracker at the top of the request so once deleted, if you were to go back to an old request, you wouldn't have visibility of the stages or checkpoints that the request went through and possibly no indication of what workflow a request had used.

Yes, I have this flagged for moving to docs.hornbill.com. Hopefully we will see all the remaining pages on the wiki moved over soon.

A fix should be available in the next platform update

Thanks for your post. I've fed this back to our development team.

An issue was confirmed and a fix has been patched to correct this.

Hi Adrian, Yes, this is expected behaviour. You either use a View or you use the request type filters, but not both at the same time. Only the quick filter on the far left works with the currently selected View.

There are some changes in our backlog to extend the features that are available in the bulk update. Over time we hope to include most of the options that are available across the top of an individual request. These are not scheduled for development as of yet, but we will continue to improve this area over time.

Hi @Sam P For any process or request type where a customer is required, I'd start by making sure that there is a Wait for Customer node near the beginning of the workflow. If the customer is provided, the workflow will automatically move past this node and continue. If the customer wasn't provided, you can make sure that the person that copied the request also is forced to add the customer once the request is raised. Putting the Copy feature aside, if there are any dependencies in the workflow that requires there to be a customer such as sending an email to the customer it is always worthwhile having these types of checks. Not all request types use the customer option and for those that do, the customer is optional within the request form. The only place where the adding of a customer can be made mandatory is within the Intelligent Capture workflow. Different customers and the services that they provide may all want to work with this differently so a blanket option to make the customer mandatory on the copy request from will be problematic for some. The workflow is really the place where you can make sure the requests have the appropriate information that you need while providing the flexibility for other services or departments to work differently. I hope that helps.

Hi Peter, The references mentioned in these documents can be found here. I'll look to see how this can best be added to the documentation. I'd like to have this all within the documentation and not have a link to an external source. For now, I hope the link above helps.

Hi @CraigP It would be hard to say without getting access and viewing where you are having the issue. As a Premier Success customer you may want to get directly in touch with Hornbill Support and report this.

Hi Adrian, I'm wondering if the users (connections) are being listed under the BCC option. The To field is not mandatory as we need to allow for when the BCC field is used and you don't want to expose any of the recipients to each other. Using the BCC field for connections can make sense, especially if the connections are external contacts, they may not want their email shared with other customers.

That's great news that you got it working.

This might be related to the Admin user being listed and counted in the list, but the Admin user doesn't take up a subscription license. I'm not aware of any changes. It is possible that at one time the admin user was being included in the utilization, and this has since been corrected.

Hi Lee, Thanks for your post. It can be tough to have an idea what is happening without taking a look at the whole picture. However, I will try to provide a few options to consider. You may have looked into these already, but do let us know if any of these help or if you are still having problems after checking these out. 1. In the workflow above the Start Response Timer and Start Resolve Timer come before the setting of the priority. The Service Level targets will be set as soon as these timers start. If you have a rule that is looking to set a target based on priority, you should be able to move the setting of the priority before the starting of the timers. 2. If you have some rules set up, but none of the rules match, no service level is applied, and therefore the timers wouldn't start. 3. There is a workflow node that will automatically re-assess the service level target. If there is any change in priority or other criteria that you use within the rules for setting the service levels, this will re-apply the new targets. 4. When there is more than one Service Level Agreement available to a Service, you must provide a rule to make sure the correct Service Level Agreement is applied. 5. When there is more than one Service Level on a Service Level Agreement, you must provide a rule to make sure that the correct Service Level is applied. 6. Both Service Level Agreement rules and Service Level rules are applied in the order that they are listed. You need to make sure that the criteria for a rule at the top of the list doesn't match something that you are expecting to be picked up by a rule further down the list.