Jump to content

Search the Community

Showing results for tags 'workflow'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Hornbill Platform and Applications
    • Announcements
    • Blog Article Discussions
    • General Non-Product Discussions
    • Application Beta Program
    • Collaboration
    • Service Manager
    • Project Manager
    • Supplier Manager
    • Customer Manager
    • Document Manager
    • Configuration Manager
    • Timesheet Manager
    • Live Chat
    • Board Manager
    • Mobile Apps
    • System Administration
    • Integration Connectors, API & Webhooks
    • Performance Analytics
    • Hornbill Switch On & Implementation Questions
  • 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

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Organisation


Location


Interests


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype

Found 7 results

  1. When configuring SLA response and resolution targets and expiry times on certain BP nodes you might find the target being set differently than possibly expected. This is because a common oversight as these timers needs to be expressed in SLC (Service Level Calendar) times or working hours or business hours (which are usually X hours/day) rather than calendar time (which is 24 hrs/day). When configuring a target time of N days, the value needed to be set would be N working days rather than N calendar days. The value that needs to be set will be obtained by multiplying N with the number of working or business hours/day. We advise to always configure hours (rather than days) as it is easier to figure out the values required to be configured for SLA targets or expiry times on business process nodes. However, in certain areas (e.g. SLA timers), depending on the target, it might not be always possible to use hours exclusively. Below is a quick example of how to find out which values needs to be configured depending on the intended target: Let's say we need to configure a resolution time (or an expiry time) of 5 days. We need the target to be set in 5 days from now. Let's also say the working hours are 7.5 hours/day although this really depends on your SLC. Step 1 is to find out the number of working hours equal to the 5 days we need to set: 5 days * 7.5 hrs/day = 37.5 hours. You need to configure round values therefore if you don't have a round number of hours you also need minutes (seconds, etc.). The 37.5 hours equates to 37 hrs and 30 min. In conclusion, for a 5 day target, the configuration needs to be 37 hrs and 30 min. As mentioned above, for simplicity always use hours if possible. If you need to configure this value as days/hours/min then the 37.5 hours need to be divided by 24 (which is the number of calendar hours in a day) resulting in 37.5 / 24 = 1.56 days. The 1.56 days equates to 1 day and 13.50 hours. This further equates to 1 day 13 hours and 30 min. In conclusion: 5 day target in the context of 7.5 working hours/day is set as: 37 hours and 30 minutes or 1 day 13 hours and 30 min If you don't want to be bothered with the mathematical calculation, you can use this Excel sheet to find out what values you need to configure. Type in the desired target time and the number of working hours per day. The values you need to configure are in red: Hornbill_Timer_Targets.xlsx IMPORTANT: the above does not apply when configuring expiry times on human tasks. Human tasks do not account for Working Time Calendar and as such the above setup does not apply in this scenario.
  2. As you are probably aware it is not possible to have more that one input path into a business process decision node. Like this: However, there are scenarios when configuration requires that multiple paths converge at some point into one decision node. Like this: If you try and create a link the second node into the decision node, it will fail and this message will be displayed: "The target node has too many entry points". This scenario has been catered for by introducing an "intermediate" node in which all nodes converge before the decision, then create a single link between this intermediate node and the decision. There are occasions when this "intermediate" node is actually required in the process design but sometimes there isn't any so a simple choice would be to use a generic node. The obvious and most used choice is "Get Request Information - Get Request Details" node. Because this node one retrieves information/data about the request is not affecting the process progress or the associated request in any way. Like this: This is a valid configuration and works as intended and achieves its purpose. However, we think there is a better, more efficient and resource friendly way to achieve what you need (merging multiple paths into one decision node). Although there is nothing technically wrong using a "Get Request Information - Get Request Details" to act as a placeholder for a connector, it is not the most effective way, especially if is used in many places in the process. keeping in mind that the more complex the design, the more time it would take to run the process, use more resources, etc. Ideally, we would want to make it as efficient as possible. Therefore instead of using an automated task as placeholder, why not use a stage checklist node. The advantage is that you will achieve the same but without making the process more cumbersome. Like this:
  3. When making changes to a business process you might find these changes not being applied on newly raised requests. This is a common oversight and it happens because the version of the process which contains the changes has not been published. If making changes in a process and save an activate the process, the new version created also needs to be published if you need the changes to take effect in the newly raised requests. Publishing a version of the process is done from the "Publishing Manager" interface within the business process designer.
  4. Afternoon, Is there a way to automatically update the status of a request using workflow? Example When we log Change requests they are assigned to users straight away and have the status of 'Open' These Changes are pending CAB approval. When CAB do approve these requests can the workflow automatically update the status to 'Approved' so users know from their call queue they can action? Many thanks Andy
  5. Impact Assessments Capturing the impact of a change, an incident, or any other type of request can be crucial to determining how it is managed.  But how do you decide which impact level to select?   Service Manager provides a great way of automatically determining the impact level to be applied.  Taking the guessing out of the hands of the user, they can be walked through a number of questions where each answer has a weighted value that contributes to the automatic selection of the impact level.  The results of the assessment are captured in the request along with the automatic application of the impact level. At any point after the assessment, if things change or a mistake is found, a reassessment of the impact can be completed. The assessments are managed as part of a Business Process which allows them to be presented to a user at any given point within the workflow.  When defining your workflow, you can easily select from any number of available assessments that you wish to present.
  6. Hi Please see attached screenshot. The Workflow in use is ICT Change Process I'm not sure what is going wrong here. Please could you help?
  7. I have an issue with placing tickets automatically "on-hold" during stages of a ticket. Please can someone help me out with this? Workflow as follows: Request Details -> Human task (error when completed) -> Checkpoint node (completes fine) -> Automatic Email Notification (sends fine) -> BPM1 (attached) -> BPM2 (attached) -> Authorisation node -> Decision Node Regards, Mike.
×
×
  • Create New...