Jump to content

Search the Community

Showing results for tags 'sub status'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Hornbill Platform and Applications
    • OpenForWork
    • Announcements
    • Blog Article Discussions
    • General Non-Product Discussions
    • Application Beta Program
    • Collaboration
    • Employee Portal
    • Service Manager
    • IT Operations Management
    • Project Manager
    • Supplier Manager
    • Customer Manager
    • Document Manager
    • Timesheet Manager
    • Live Chat
    • Board Manager
    • Mobile Apps
    • System Administration
    • Integration Connectors, API & Webhooks
    • Performance Analytics
    • Hornbill Switch On & Implementation Questions
    • GRC Manager
  • About the Forum
    • Announcements
    • Suggestions and Feedback
    • Problems and Questions
  • Gamers Club's Games
  • Gamers Club's LFT

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start








Website URL





Found 13 results

  1. When attempting to add a Translation to a Request Sub-status, they are not saved. My also be related to our other post where the Request Type for All is not pulled through. In this case I have to set the Request Type to All on the first tab before the Save button will enable. Cheers Martyn
  2. When editing existing Request Sub-status which is set and shown as Request Type 'All' on the parent list screen in the admin tool, the Request Type is not carried through to the edit dialog window and requires manual population in order to save other changes. This could lead to the incorrect value being entered and also is unnecessary manual intervention. Can this please be populated with the current value. Cheers Martyn
  3. Relates to my earlier post below about overriding the default visibility for Email Routing Rule updates, it would be useful to be able to override the system setting on a rule by rule basis whether an update via the said rule will trigger an Sub Status Automatic update, asin our case for internal email we would not want it to do this, but for customer updates we would. Cheers Martyn
  4. Can the current Hornbill Request Import V1.2.0 be updated to include the following additional capabilities. Support the import and matching of Sub Status, only current supports parent status. Support the import and matching of Service Level Agreement and Service Level's. Extend current supported request types, Incident & Service Request, to include all other types, i.e. Change, Problem, Known Error and Release. Also as per the SQL Contact Import also support MySQL v8 connection with the new authentication method. Cheers Martyn
  5. Related to our the posts about include additional fields in the Request Reference Hover Dialog, can we also request that the sub status is display next to the request's primary status in the Linked Requests section of the Request View. Cheers Martyn
  6. Can I raise a enhancement request to have the Request Summary Pop Up dialog to include the additional fields for Sub Status and Service Level, in addition to the current primary Status and Priority fields. Perhaps this could be set up as customer controllable list via the a setting in the admin tool? Cheers Martyn
  7. We are implementing the use of Sub Statuses which are updated both by the BPM and manually. Though not an issues when updating by the BPM, when you manually change the Sub Status through the Live user app, a pop up window appears prompting for a reason every time. This creates more work and becomes annoying very quickly. Though there are certain scenarios where we would want to make the pop up and completion of the reason a required process, there needs to be the ability within the setup of the sub-status to configure if changing the request to said status requires the prompting for a reason pop up or not. In the latter case changing the sub-status should not prompt at all and just update the request. Related to this would also the ability to define against the sub-status the default visibility of the timeline update as well. Cheers Martyn
  8. I cannot seem to find the Global Sub-Statuses menu today, has it moved somewhere or am I missing rights?
  9. As part of our implementation of Sub Statuses we have created a couple of On Hold Statuses which we would only use for specific circumstances having no on-hold time expiry time. We would like to be able to restrict the use of these to certain 'authorised' users, i.e. Team Leaders/Managers, so it would be good to have the ability to restrict the permission to select a sub status value based on role membership. For example we have a Sub Status of 'Support Hold' which we use in the rare circumstance when a customer annual maintenance payment is overdue. This should only ever be used on requests by a Team Leader/Manager and ideally we would not want normal analyst to be able to select this or even better be able to see this status in the options to select. Cheers Martyn
  10. We have now rolled out the use of Sub Statuses on our services, but now have the transition period where we have global sub statuses applying to all requests, but a mixture of workflows, i.e. request logged prior to rolling this out still have workflow which are not sub status aware so only set the primary parent status values. This causes a problem as we have request being put On-Hold via the BPM, but have a sub-status of Pending, which is a sub status of Open not On-Hold. In order to then be able to 'resume' the request via the user app, we have change the sub status another sub-status value and then back to our standard Open Sub-Status of 'Pending'. Also the incorrect sub-status value causes confusion when being displayed in the Request List and in the Customer Portal. It would help with the transition if the BPM Status Update node had the ability to set a default 'On-Hold' and 'Open' sub-status when one is not specified in the BPM node. Cheers Martyn
  11. It would be possible for the pop out window when hovering over the Linked Requests to include the Sub Status as well as the parent Status value? Cheers Martyn
  12. Our workflow at the moment sets the primary status to 'New' when it is first get assigned to our 1st Tier Team and again when it is then assigned on to the 2nd Tier Team. In the latter stage, the workflow is setting the parent status to 'New' as before, but the Sub Status is not being cleared as there is no sub statuses supported under the 'New' status. I have tried updating the BPM to manually set the Sub Status value to blank, but the BPM then fails. Therefore there does not appear to be away to clear a sub status when changing the status to 'New'. Cheers Martyn
  13. Though the Sub Status field is present and view-able on the the Request List screen, it is not appearing in the condition drop down when setting up a view on the Request List. One of the main reasons we are implementing Sub Statuses is to allow our analyst to be able to differentiate and filter their request lists based on the more detailed status information offered by the Sub Status facility. Can this be added to the condition drop down as a matter of urgency? The other recent additions such as Service Level and Service Level Agreement are present, but not the Sub Status field. Cheers Martyn
  • Create New...