Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Victor last won the day on October 7

Victor had the most liked content!


About Victor

  • Birthday 02/22/2010

Recent Profile Visitors

4,991 profile views

Victor's Achievements

Grand Master

Grand Master (14/14)

  • Reacting Well Rare
  • Dedicated Rare
  • Very Popular Rare
  • First Post
  • Posting Machine Rare

Recent Badges



  1. Are these nodes using the same function/operation? If yes, no need for separate formats after decision ends... if they use the same operation then they would output the same param, just with different value... and from what I see the format is just changing the way it appears, like using the day name... so it does not matter what value it gets (and is all about value afterall) it will format it regardless...
  2. Why two sets of "Set Schedule Start/End date format" and "Add Notice" nodes?
  3. Not quite, it is actually the opposite ... Most of our customers, while many located having HQ in UK have users located all over the globe. Might be the case that their Hornbill instance is set to a specific timezone but the users will have different one based on where are they located. Regardless, the Cloud Automation would not work. Once you format that date in any shape, it will remain like this until another node re-formats it... The solution, in my view, is to have the date/time formatted in the UI based on the timezone of the user that uses that UI. This allows the system to hold a set date (GMT/UTC) while displaying it differently based on user preference. The solution or workaround would work for your specific requirement here and now since you need that BST conversion for all your users and it will only be feasible in this scenario.
  4. Getting "last Sunday in March" and "last Sunday in October" is not quite possible. The alternative is to check for the specific date. I understand the date for daylight saving is different every year but that's yearly so updating the workflow once a year is not that cumbersome, I think... even so I expect the wiki date format in notices to be implemented soon(ish) so I don't expect a yearly workflow update to go on for too long... Anyway, if one wants to implement this check for BST based on the specific date this can be done as follows: 1. Have a Cloud Automation Utility node to retrieve current timestamp. Like this: Operator param is mandatory so it needs to be set but for our purpose it can have any value, we are not actually adding or subtracting any value here because: 2. All other params will be set to ignore. The Starting Timestamp as ignore will use current date/time and the other values set to ignore means we are not altering this current date/time in any form for the Timestamp output param value. 3. In the workflow continue with a decision node that will check in the value for Timestamp output param (returned by the Cloud Automation node) is less than, let's say 2021-11-01 00:00:00. If yes then it means the current date/time falls within BST, if the value is greater than 2021-11-01 00:00:00 then it means the current date/time falls is outside BST. Example for how the expression looks that checks if the date/time is within BST:
  5. @Gareth Watkins was already reported, we're looking into it. I will close this thread to avoid duplicates please follow and contribute on the existing thread:
  6. @Paul Alexander can you have a look or ask the network guys to check the URLs for the Azure app set for Hornbill service? Perhaps one of those URLs is incorrect and would need an update... I am saying the above based on the troubleshooting document from MS: https://docs.microsoft.com/en-us/troubleshoot/azure/active-directory/error-code-aadsts70001-app-not-found-in-directory
  7. @Paul Alexander looks like you are using Azure as IdP (correct me if I am wrong). If so, do you have an Azure app for Hornbill service portal?
  8. @Berto2002 no idea... I can suggest raising a support request if you need this investigated in more detail...
  9. Hmmm.... how? Is this a recent workflow? We have a check in place that looks for this oversight, preventing publishing for that version... example: EDIT: looking a bit further into this, it seems that is possible to set a mandatory checkpoint as False. In effect it means it will not set that checkpoint, but for the validation mechanism it appears valid as the checkpoint is set somewhere in the stage... hmmm... This aside, if you happen to get this error it will be on the node that progresses the flow to the next stage. Edit the affected running workflow, it should look like this: Edit this node and add the missing checkpoint (for example, Incident Assigned checkpoint): Save changes and restart the workflow.
  10. @Hiten unfortunately this can't be easily troubleshoot just with the screenshot... I'll send you a PM
  11. @Jeremy just checking if this is now working ok for you ...
  • Create New...