Jump to content

Berto2002

Hornbill Users
  • Posts

    1,303
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by Berto2002

  1. @James Ainsworth and @Victor. This seems like a great candidate for a Cloud Automation enhancement doesn't it? Either a new Cloud Automation Utility or something to simply check to "Get User Timezone" to enable a conversion. In the meantime, I will go with the manual re-configuration Victor has suggested as it's in my area of control and get that in and tested before the end of the month.

  2. Hi James. I understand how if it's a text field then it will show as GMT; because the system is tracking everything in that zone.

    Yes, the information displayed in the Notice is picked-out from the "Scheduled Start" and "Scheduled End" dates of the "Get Request Information" node; and then passed into the Cloud Automation format it to be user-friendly. Me seeing that as derived from a Data/Time field naively assumed the UI would then interpret that to the user in the Notice in their timezeone. 

    It looks like the product is currently unable to display a reliable date and time in the Notices because of this design anomaly; hence why I was asking if there are any ways to work around this in workflow: to convert the GMT system output to BST during daylight savings only.

    So the challenge is whether there a way to code "last Sunday in March" and "last Sunday in October" into a Customer Expression so the workflow can either add or not add one hour!?

    In the UK the clocks go forward 1 hour at 1am on the last Sunday in March, and back 1 hour at 2am on the last Sunday in October. [When do the clocks change? - GOV.UK (www.gov.uk)]

  3. I'm still struggling with how to convert the system default GMT timezone to BST when displaying in the UI. Can anyone help with what utility to use and configure to display BST?

    I have the following nodes with the idea that a big banner goes across Authorised Change Requests to make it very clear when the window is open from and to.

    image.png.3b7fa744b38d5e956b3456de78bb0487.png

    The Cloud functions change the format into something readable. They use this approach:

    image.png.efdfdc3cbdd186c93239f8c7fb748fd9.png

    I then add the Notice but the result declares as GMT, the system default which is one hour out from BST giving me the risk they mis-read it and start the change at the wrong time. My users want to see BST in the Notice (obviously) because we're in the UK.

    image.thumb.png.14feac16a97365145e4bd659076c8dc1.png

    What is the Util and config I need to add one hour to the GMT when UK is in BST? I guess I am, looking for a "Convert Timezone" Cloud automation?

    image.png.70b2ecc3c5d82f060015af009d693d50.png

    Or has anyone worked out a workflow approach that checks, for example, if the UK is in Daylight savings period and if so adds one hour to the displayed time? What would I use as my external reference lookup to get that 'fact'?

    I am trying to resolve this before the clocks changes because for the whole of the winter the timezone in the UK aligns with GMT so we won't see the issue!

     

  4. I see a need to have a kind of trigger process acting on some Requests that "watches" a Request through it's workflow and fires-off an AutoTask if certain criteria are met. The key difference between this suggestion and any existing "decision" node is that it is 'floating' and can fire at any time. Hornbill Service Manager has a great strength in the workflow approach but it has a weakness in that it does not provide for those circumstances which cannot be predicted.

    Use case:

    We have set-up our Major Incident process to perform a number of actions for an MI that don't happen for normal Incidents such as:

    1. Set-up a Teams Channel for collaboration
    2. Email the Ops Management team for immediate awareness
    3. Prefix the Summary
    4. Create a Problem record (later used for Tracking causes)

    But the above flow is configured to follow-on from the initial logging of an Incident with Priority Major. Once that point is passed, changing the Priority to Major has no effect and we rely on manual efforts again. It is quite often that an Incident comes-in quite innocuously from a user as a Medium or High Priority and we then need to move it up AFTER triage. I am working on an AutoTask that we can use for these four actions but it will still need someone to press the button.

    My suggestion is that a new Feature of, say, "Triggers" could be added (in a similar way to Custom Button functionality) and the criteria in Triggers would not show a button but would fire the AutoTask directly if the criteria were met. I would configure it to fire on:

    1. Request Type = Incident
    2. Status = NOT Resolved, Closed, Cancelled
    3. Priority CHANGED TO Major

    Other use cases:

    1. How about having one that looks-out for various user responses like "escalate", "not happy", "supervisor" and have that Trigger notify the Service Desk Manager that something could be going wrong with the customer interactions on that ticket?
    2. If a Change is raised on a certain Service or is linked to a certain Service during it's lifecycle, certain notifications can be made to stakeholders

    I agree it is potentially possible to think through when these AutoTask processes might be run and to duplicate elements of the workflow in the core BPM on a "what if" basis. But that requires a lot of work and duplication. Interestingly, it would be easier if it were possible to move back to other stages of a BP because we could configure have regular "loop-back and check" cycles which would only act if certain criteria had been met since the last check.

    I would be interested if other users can also see usefulness in this feature idea or would have other ideas for how/where it would be most useful.

  5. In our Change Request workflow, we have the concept that the Change Manager can remove the Human Task that the Implementer uses to declare the Start of the work. This effectively means they won't proceed because they are trained to use this task before starting. This can happen if, for example, new information comes to light about the CR any time between the time it is Authorised and the Scheduled Start Date. The case in point today is that the pre-cursor tests failed. Another case we have is expiry: if the Start is not declared before the Scheduled End date (missed window), the task moves on. My workflow then gives a task for the Change Manager to review the position before either amending the Schedule or the Plans and re-Authorising or Rejecting.

    Here's the enhancement. I want to UN-Authorise the Change Request at that point so it very clear that the work may not proceed. If the CM authorises, in their review, it will again be Authorised in Service Manager. At the moment I am in the position of having a CR that clearly states "Authorised" and my technical staff could debate that they implemented an Authorised CR even when I've tried to stop it for very good reasons...

    But here's the issue. The node for Authorisation Decision has no option to "Remove" an answer previously given: we have only Approve or Reject. I do not want to reject it (we are enablers to change not blockers). I request an option here to return the Change Request to the pre-authorisation state of null decision, please. If not in this node, is there another way to achieve it?

    image.png.210631c4c8a04c2c31ccc1017368355e.png

  6. 3. Use case. At some point I need to have my CR re-authorised for some reason so I need an AutoTask to update the RequestID to be unauthorised and then for me to INPUT the name of the person to whom I am pushing the Approval out to; with a choice to use the internal Authorisation or External Authorisation nodes. The result of that is received and updates the RequestID again. I can have 'gates' in certain other nodes that only allow the workflow to proceed if the authorisation is still present.

  7. Hi,

    I am getting used to the AutoTask idea but I get limited by the fact it cannot accept inputs from the Agent on which to act. I request you please enable a Human Task node type to be used in Autotasks. The node would 'pop-up' just like any other Human Task but would send it's variables, outcomes and results to the AutoTask not the core BPM.

    Example use cases:

    1. My Service Desk periodically need to make updates to Assets (e.g. phones, laptops) including altering the Used By and changing the status to show, say, if they are deployed or in storage. This happens in a number of workflows such as leavers, starters, movers and sometimes standard service requests. Users are unpredictable beasts and they don't always turn-up and want or give stuff at the exact moment the Hornbill workflow expects it. To keep our assets under control (and without asking our SDesk to browse into Asset Manager and do the updates there), I want a Custom Button that starts an AutoTask that allows the Agent to update Asset fields at almost any time (I will set criteria such as status.open and assigned to Service Desk, etc). To do that, I need a Human Task in the AutoTask with the usual configurable form to specify what can be updated.
    2. I want to start sending communications to my users through workflow but workflow is overly prescriptive because it pre-defines when I may or may not need to send comms (i.e. the stage or node at the time). I need to send "at any time" when I am in a major incident or a change. If a Custom Button could launch an AutoTask that had a Human Task to capture text like, say, "The Incident impact on users", "what we are doing about it", the "service" (from RequestID), the subscriber list or email address/es to send to and "when we will next update you", then I would be able to use that button when necessary. Meanwhile, the core workflow is uninterrupted but the AutoTask can update a custom field to state comms have been sent
    3. More to come. I will append to this post when I come-up with the next reason why a Human Task in AutoTasks would be extremely useful.

    Berto

  8. @Miro. I have just been to the "Co-Workers" tab of Collaboration. When I click this link to find Co-Workers it ONLY RETURNS FULL USERS (of which we have 77).

    And yet, in Service Manager, as per the start of this thread, when I select "Just Co-Workers" in the Human Task dynamic lookup, it finds a mix of Full and Basic Users.

    In short, the applications are INCONSISTENT in their treatment of the filters for "Co-Workers".

    Back to my point, I believe the filter of "Co-Worker" was designed to capture only those users who either have "User" Account Types or who are consuming a licence such as those with "Service Manager" Roles or "Collaborator Role".

    So I put it to you that the BP designer has a defect in allowing Basic Users to be found and selected when the "Just Co-Workers" option is selected. that defect is not manifest in Collabotion application itself.

  9. Not really @Miro because if I want to select only from (Full, licenced) Users (i.e the ones that can perform Service Manager functions), then I have to select "Just Co-Workers" BUT I also have to do a major data update to tick the box for 95% of my Co-Workers to exclude them from that list; and ensure my process reliably ticks that box each time we add a user!

    The concept of a Full User is as clear as the concept of a Basic user in the Hornbill User Admin so I don't understand why you would not design it so I can reliably select all my licenced (Full) Users; the most common function.

    Another way to put this is that the Basic Users are included in the Co-Workers list unless excluded with that tick-box which leads no way to select only Full Users

  10. @Miro. Can you go one better please?

    At present, you have "Co-Workers" and "Basic Users" in your dynamic drop-down. This is a bizarre mix of licenced users and users that meet a certain criteria (a tickbox)

    What I believe you should have is "Co-Workers", "Basic Users" and "Full Users". The fact Full Users is missing from that list strikes me as an oversight.

    That would enable us to select Full Users who are usually the only people we need on those drop-downs.

  11. I've detected what I think is a risk in our Change Request approval flow by unexpected behaviour.

    In a Human Task, we ask the Change Manager to specify a number of Approvers for a CR using the "Hornbill user picker" which we set to "Just Co-Workers". My understanding of that is it should allow only those with a Full licence to be selected.

    image.png.503b34e60a569978c824e59ab51003a3.png

    And yet when I go to use it, it is still showing users who are Basic users and those with Full licences but Suspended status. This will clearly create issues if either type are selected.

    From the user admin list, one Claire is Basic and one Claire is Suspended:

    image.thumb.png.02cb7d449f2643996067c8a905d79255.png

    But when using my selector in action, both Claire's could be selected.

    image.png.13b7628a37d028b75a0d65089e8db105.png

    My instinct is that the "Just Co-workers" filter is not working as designed; it should exclude all Basic and Suspended.

    Can I have a view on this please?

    Thank you

    Berto

     

  12. Hi @Steve G, we've got it working, kind of...

    The problem that prevents us using this is that the connector is posting to the Teams Channel as the personal account of the admin person who gave the approval; in this case "James". How do we get the post to appear to come from either a generic account such as "Service Desk" or from the Owner of the Hornbill Request, for example? This is a bit of showstopper.

    Up until now, we have been using the feature to email new conversations to the Channel and these have been coming-in with the Summary as a formatted header to the conversation (blue below). By moving to the new connector to start and reply to conversations we would lose that by the looks of things. I tried using Wiki markup in the Content of the Teams node but it's not worked (Pink below) Are there any options for formatting available or could you look into that for development?

    image.thumb.png.01a6da745429fea7f03356f530166708.png

    The other issue is that the status code is showing as "Failed" in the Timeline update but the Conversation is being initiated and an ID returned:image.png.a99d3daf38c2814c58f20c7598172ebe.png

    Overall, exciting to get this working but...

  13. I have adopted a similar approach. The button only appears when there is a specific value in a custom field for a given Request Type. I have workflow that sets the value to "Offline" at a set stage of the process. My custom button only shows when that is the case. The Autotask of that Custom button sets the value to "CAB". Then, when the workflow gets to another point it looks to see if "CAB" is in that custom field; if so it diverts. If any other value (including Offline) is in the custom it proceeds as normal. This gives the effect that the button only shows for a brief period but it it is used in that period it disappears as soon as it is used. This enables our Change Manager to send a CR to CAB during it's offline approvals even if a previous decision was made that it doesn't need CAB.

    • Thanks 1
  14. Mapping Fields from Customised Forms - Hornbill states, "DATETIME custom fields 21 - 25 each suitable for holding a single date-time stamp (YYYY-MM-dd HH:mm:ss). These columns should ONLY be used in conjunction with a date-time picker."

    I want to start to capture the ACTUAL start and end of the work on a Scheduled CR so we can assess compliance with the schedule. We have "Start Implementation" and "End Implementation" Human Tasks to give us the point in time.

    I was planning to use a Get Timestamp Cloud Utility node directly after each of those Human Tasks and map that result to a custom field (one of 21 to 25) but due to the warning in the Wiki page I am concerned about that. Do I need to manipulate the Get Timestamp node result (with a String Util?) before it will be compatible with the custom field 21-25 formatting?

    Regards,

    Berto

  15. I have just tried adding-in the Cloud Get Timestamp nodes with one getting the current time and one getting the time plus 5 minutes.

    Those outputs are then fed into the Variables of the Update Change Calendar action in node "add current date time to schedule"

    image.png.b2f8061fae6a77b150c38496fc584230.png

    image.png.5fc1d42af90e8488b1ffa1c53140be27.png

    The result of the TimeLine update is a bit different this time:

    Outcomes of Schedule action: &[global["flowcoderefs"]["addSchedule"]["outcome"]] - &[global["flowcoderefs"]["addSchedule"]["isScheduled"]]

    Looks like: image.png.d12d1c54754c9f7de96b6189573eeeb6.png

    So the node that is supposed to add it to the schedule is declaring SUCCESS but the result is that it is NOT successful.

×
×
  • Create New...