Jump to content

Berto2002

Hornbill Users
  • Posts

    191
  • Joined

  • Last visited

  • Days Won

    4

Berto2002 last won the day on September 13

Berto2002 had the most liked content!

1 Follower

Profile Information

  • Gender
    Male
  • Location
    Southend-on-Sea

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Berto2002's Achievements

Community Regular

Community Regular (8/14)

  • Reacting Well Rare
  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done

Recent Badges

17

Reputation

  1. My field services lead has showed me this error that appears immediately when a Guest account attempts to log a new Request in the Customer portal: I think this may be caused by the Customer Search in our standard PCF which is not playing well with Guest Accounts. Note that the user can proceed to log the Request and it does capture them as the customer and workflow otherwise works ok. This PCF was set-up by our consultant in the project so I'm not very familiar with it. I was not able to find detail to help me decide what to do on the Wiki: Progressive Capture Designer - Hornbill. My instinct is that I may need to have a branch at the start to detect if it's a Guest and if so to use a Contact Search instead of Customer Search before going back to the Details Custom Form. Can anyone please guide me here so I can make the right development?
  2. Each one is using a different input because the format change nodes do not alter time. The ones down the No Match route use the raw scheduled dates/times from the Get Information node and the ones down the BST route use the outputs from the "+1 hour" nodes. I don't know a way to specify one such node can accept either of two inputs.
  3. I got the workaround working so my Notice now tallies with the local timezone: These are my nodes:
  4. I can see the conundrums here. All I can do is express that a requirement to allow times to be displayed in Notices - picking-up the user timezones like other fields in the UI - would be useful. I guess what you guys do with that information is up to you now.
  5. That's a good point. So it would need to be a Cloud Automation to output the date in a specified timezone. For MOST Hornbill customers, they would operate a standard timezone for the whole organisation.
  6. @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.
  7. @Jeremy I would be very interested to know what you're using for this! Passing out to where; a cloud-based service we can also use or bespoke local code?
  8. 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)]
  9. 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. The Cloud functions change the format into something readable. They use this approach: 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. 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? 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!
  10. Yes I am working to move those actions out of the workflow and into a custom button. But the point here is that it remains manual to action it whereas my suggestion is that a Triggers functionality could be a very effective automation tool for workflows that should be automated but do not happen at a set time in the Request lifecycle.
  11. 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: Set-up a Teams Channel for collaboration Email the Ops Management team for immediate awareness Prefix the Summary 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: Request Type = Incident Status = NOT Resolved, Closed, Cancelled Priority CHANGED TO Major Other use cases: 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? 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.
  12. 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?
  13. 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.
  14. 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: 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. 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 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
×
×
  • Create New...