Jump to content

Berto2002

Hornbill Users
  • Posts

    1,303
  • Joined

  • Last visited

  • Days Won

    28

Posts posted by Berto2002

  1. OK so this is for Administrators only? Most of my Agents cannot see this BPM back-end view. This means any Agent who finds themselves in this position needs to appeal to a Hornbill Service Manager Admins for help. I was hoping you would/could expose this option to the Agent to over-ride themselves. Please consider that option too. However, the feature you describe would be useful insofar as our Service Desk Manager has Admins permissions so could be the contact for the Agent to perform this over-ride. I look forward to it.

  2. James, this is an interesting idea. The switch meaning that the Std Chg Cat Items could be 'hidden' from normal views and just operate in the background. The advantage of this approach is that the Cat Item (and thus the type of standard change) would be visible on the main Request view. However, we are trying to state to our agents that the procedure approved in the original CR is the benchmark and unless there is a link to that, the Agent needs to always manually search to find it.

    The product contains the facility to Add Connections and to Add Assets. It seems logical that an enhancement idea for Adding Linked Requests could be worth considering. However, I appreciate the view may be that Requests are 'transient'. But then think of how this could be used to automatically link Incidents with Known Errors also; KEs tend to stay around a lot longer and I can imagine SDesk being presented with an option to select a list of KE's in a Human Task. But even better; simply allow the Dynamic Drop Down boxes in the Capture Fields to search against the Request Summary and/or RequestID table and this really helps.

  3. We have set Standard Change types in a SimpleList and I would like to have the new Request workflow automatically linked to the original Standard Change based on a user selection in PCF.

    Workflow would be along the lines of:

    1. User selects Standard Change Type in Human Task (Simple List with RequestID of the original record as the Value)
    2. Workflow Gets RequestID outcome from the PCF
    3. Workflow "Adds Linked Request" with that RequestID

    Then we can report on the number of iterations of that Standard Change we have go through the system and control which is referenced through the SimpleList updates via CAB.

    But the Linked Requests only has "Update" and "Resolve" not "Add" options. Is this possible another way?

    The best I can think of to refer over is to add the Raw Value from the SimpleList to the External Reference field to make it at least reportable and visible.

    image.png.6e6a68daac31edd4ba90b4af7f03266d.png

  4. Hi @Victor, @Steve Giller. I have got around to re-testing this and have now output the details the failing node is using to the TimeLine.

    The expressions in the failing node and the TimeLine update are:

    &[global["flowcoderefs"]["getCardInformation"]["cardId"]]
    <span style="font-size: 11px">'''Summary:''' &[global["flowcoderefs"]["getReqInformationExpedited"]["summary"]]</span>
    <span style="font-size: 11px">'''Start:''' [&[global["flowcoderefs"]["getReqInformationExpedited"]["scheduledStartDate"]]]</span>
    <span style="font-size: 11px">'''End:''' [&[global["flowcoderefs"]["getReqInformationExpedited"]["scheduledEndDate"]]]</span>

    The result arrives as the following with 770 being the CardID output:

    image.png.8320c5ed6ca3069b0db61719d9924d4b.png

    The two nodes leading up to this one work ok. Notably the one that moves the card in the lane works fine.

    image.png.8ce7d780d2ada5072ec04ce2c4bd1b5c.png

    The Update Card node fails regardless of whether I leave the CardID field as Auto (as the Move Card node does and works) or if I use the look-up to specify the CardID from a previous Get node.

    The log states:

    2.034924s ERROR Execution Failed: Xmlmc method invocation failed for BPM invocation node 'stage-438aaf27/flowcode-dd35290c': <methodCallResult status="fail"> <state> <code>0207</code> <service>apps</service> <operation>updateCard</operation> <error>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js(189): error X1001: Uncaught EspMethodCall::invoke: Operation[apps/com.hornbill.boardmanager/Card::updateCard] FlowCode Exception (com.hornbill.boardmanager/entities/Card/fc_ops/updateCard): nodeName: Update Card; nodeId: b9e6bd6a-057a-47e3-8b93-074bfdb84e2a; At 251/1: &quot;Uncaught TypeError: Cannot read property &apos;record&apos; of undefined&quot; throw(e); _fc_node_exec_b9e6bd6a_057a_47e3_8b93_074bfdb84e2a</error> <flowcodeError> <where>Execute</where> <filename>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js</filename> <lineNumber>189</lineNumber> <columnPos>20</columnPos> <message>Uncaught EspMethodCall::invoke: Operation[apps/com.hornbill.boardmanager/Card::updateCard] FlowCode Exception (com.hornbill.boardmanager/entities/Card/fc_ops/updateCard): nodeName: Update Card; nodeId: b9e6bd6a-057a-47e3-8b93-074bfdb84e2a; At 251/1: &quot;Uncaught TypeError: Cannot read property &apos;record&apos; of undefined&quot; throw(e); _fc_node_exec_b9e6bd6a_057a_47e3_8b93_074bfdb84e2a</message> <errorCode>1001</errorCode> </flowcodeError> </state> </methodCallResult>

    I have reached the end of my ability to diagnose this issue without assistance. I hope you can help.

    Cheers,

    Berto

  5. I want a certain type of (Standard) Change request to be added to the Scheduled Start and Scheduled End Dates directly after a Human Task is completed. The business case is for logging instances of Standard Changes like firewall rule changes quickly and easily with my Agents having one Task to both state it was done and when.

    I configured this node and set the Start Time from now to 0 and then tried 1 but neither actually populated the Scheduled Start and Scheduled End and the CR did not appear on the Change Calendar.

    image.thumb.png.34c2df778e9a39670647b47f2a0eef43.png

    I added a node to update the Timeline directly after:

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

    and the result was: "Outcomes of Schedule action: success -" (i.e. missing the "isScheduled" outcome.

    Schedule was still blank. I was expecting it to populate the Start and End:

    image.thumb.png.2e309db724987fb94e69a44a53773548.png

  6. I'm experimenting with this approach which appears to work:

    1. Create a Simple List with entries for all the Service Portfolio Services you would want your Agents to select if they altering the Service of a Request
    2. In the Simple List, set the Value as the numerical ServiceID
    3. Add a Human Task to allow the Agent to select an entry from the Simple List
    4. Use that entry as the Variable input for the Update Request Service node action
    5. [Optionally store that value in custom field or output to Timeline]
    6. [Optionally have that Human Task expire so if the Agent doesn't exercise the option 'immediately' (2 mins?), workflow moves on; or they can just complete the task]

    There are options there to also update the Business Process but I haven't experimented with that; it seems 'dangerous' as there could be all sorts of dependencies in other BPs and from their proper PCFs, etc that our testing regime could spiral.

    Simply having the listed Service correct is helpful for all sorts of reasons for Agents during the workflow and for reporting afterwards, even if the BP in the background is incorrect.

    I'm also toying with how I then systematically store these Service 'flips' for reporting.

    Any feedback appreciated on improving this or alternate methods. It would sure be great to be able to do a lookup in the Human Task for a list of Services instead of having to duplicate that in Simple Lists, for example.

    image.thumb.png.33946ce86a04963c2d03bffe45175afe.png

    image.png.66af59a604b5fff489c5d6232e6ebf8e.png

  7. @Victor hahahahahaha!

    I very much appreciate your explanation and the solution proposed has worked! This is a very useful feature. I assume the same is true for when the User Picker operates.

    May I rhetorically ask, though, that I hope you can see this was not at all intuitive for a Hornbill user like myself. I am not sure many of us out here would have ever discovered that as a solution. May I suggest you run an internal enhancement request to see if that can be improved?

  8. Am I doing this correctly?

    A Human Task to capture which team should get the Ownership of a new Request created by workflow:

    image.png.13029f15a6735db08de9e2840cbcf132.png

    That task outputs to the TimeLine with the "Assigned Team" and then I have added an additional Update Timeline node to see the result.

    image.png.81c094f04e1e7a5efe60f10e4a898a97.png

    Note that the Timeline gets the full 'system name' of the team, complete with the spelling mistake that is present in the Organisation Group ("...Suppirt")

    image.png.d358cc76bc74e70c523da7915c50d3ca.png

    I then have a node that creates a new Request and the Assigned Team outcome from the Human Task is added as the Team for the new Request: "&[functions.getTaskAnswers("task-9812e30a").ActionTeam]"

    image.png.baaa3e4e94911b649af1a1e0b9b529e2.png

    But it does not pick-up that team when it is logged.

    It feels like the User Group picker on the Human Task is giving a result that the Assigned Team node of the Log New Request cannot interpret. The same is true whichever team I select.

    image.png.d9364f5852f976c33726fb99cf4771f5.png

    Any help appreciated.

    Berto2002

  9. @James Ainsworth. We cannot do as you suggest. I think the trend to move to cloud is removing that capability. My technical guys tells me this:

    Current setup: We have an O365 Security Group for each major application and we use that to import users into Subscriptions in HB. This is currently managed by manually adding users to the AD group but we are looking to automate that.
     
    What we had hoped: We hoped we could just mail-enable our Security Groups but mail-enabled Security Groups don't exist in O365.
     
    Hornbill advise (above): Create DL's to use to send mail to but this means we would need to create another list/group in AD to manage because the DL can't be used as an import group. This would give us 2 AD groups per Subscription; doubling our overheads.
     
    Other options? There is something called an "365 Group": these would work with mail-enablement but the problem is that this would then enable other services for the users in the group such as sharepoint/forms/etc and will also email the users to say they are in this group which we don't want to do.
     
    The upshot? We are stuck and cannot use the Product to contact our own users :-(. We REALLY want Hornbill to accept the usefulness of a Product feature to join the existing dots and to allow us to contact members of Subscribers through workflow; be that email or, say, an integration like Teams.
  10. What I thought would be a very simple operation has caused a failure. Can anyone help please?

    I have a node that I want to update an existing card but I get this error message:

    2.550454s ERROR Execution Failed: Xmlmc method invocation failed for BPM invocation node 'stage-438aaf27/flowcode-dd35290c': <methodCallResult status="fail"> <state> <code>0207</code> <service>apps</service> <operation>updateCard</operation> <error>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js(189): error X1001: Uncaught EspMethodCall::invoke: Operation[apps/com.hornbill.boardmanager/Card::updateCard] FlowCode Exception (com.hornbill.boardmanager/entities/Card/fc_ops/updateCard): nodeName: Update Card; nodeId: b9e6bd6a-057a-47e3-8b93-074bfdb84e2a; At 251/1: &quot;Uncaught TypeError: Cannot read property &apos;record&apos; of undefined&quot; throw(e); _fc_node_exec_b9e6bd6a_057a_47e3_8b93_074bfdb84e2a</error> <flowcodeError> <where>Execute</where> <filename>/apps/com.hornbill.core/flowcode/fc_modules/xmlmc.js</filename> <lineNumber>189</lineNumber> <columnPos>20</columnPos> <message>Uncaught EspMethodCall::invoke: Operation[apps/com.hornbill.boardmanager/Card::updateCard] FlowCode Exception (com.hornbill.boardmanager/entities/Card/fc_ops/updateCard): nodeName: Update Card; nodeId: b9e6bd6a-057a-47e3-8b93-074bfdb84e2a; At 251/1: &quot;Uncaught TypeError: Cannot read property &apos;record&apos; of undefined&quot; throw(e); _fc_node_exec_b9e6bd6a_057a_47e3_8b93_074bfdb84e2a</message> <errorCode>1001</errorCode> </flowcodeError> </state> </methodCallResult>

    This is the flow and route:

    image.thumb.png.62751de484101de0fbe16fd7e110757b.png

    In the Update Card node circled in yellow, I use this expression to get the CardID from the circled green node on the left: "&[global["flowcoderefs"]["getCardInformation"]["cardId"]]"

    I then use this expression in the Content to provide my updates on the Card; and they derive from the other green-circled node in the middle above:

    <span style="font-size: 11px">'''Summary:''' &[global["flowcoderefs"]["getReqInformationExpedited"]["summary"]]</span>
    <span style="font-size: 11px">'''Start:''' [&[global["flowcoderefs"]["getReqInformationExpedited"]["scheduledStartDate"]]]</span>
    <span style="font-size: 11px">'''End:''' [&[global["flowcoderefs"]["getReqInformationExpedited"]["scheduledEndDate"]]]</span>

    image.thumb.png.a7e96a0d7b6e0ae4fde1c00f1167741a.png

  11. Hi @TrevorHarris. It helps a bit but there are two issues remaining:

    1) the Wiki Markup doesn't alter the line spacing so you can see we end up with smaller text but it takes up the same vertical space

    2) There is a 'big chunk' of margin at the bottom of the card which obscures the text if it wraps. You can see it below. There's almost two more lines of text that could fit here.

    Hopefully something you might consider. I'm not going to bang the drum on this any more because it's not a big deal in the grand scheme of things :-)

    image.png.b6b736bfc7e3f5fdf793b679166bf8db.png

  12. Yes @Steve Giller that is what we call the OLD process we have been using. It is not ideal because it means the workflow does not move-on when the approval is received from the authoriser. It relies on manual intervention and assessment. Part of our automation agenda was to move to the External Authorisation mode which enables the workflow to move-on automatically.

    But that gives the problem that the workflow is 'stuck' for 3 days (expiry) if we either send it to the wrong person, we find it was sent in error, their manager says to JFDI or the person calls / messages us through another route (like Teams) to give the go-ahead.

    My hope is that @Gerry has seen that rock-and-hard-place scenario and can offer the Ext Auth process a 'way out' for our Agents rather than just waiting 3 days for the expiry.

  13. Hi @Gerry. I get the bit about the 'third' option for the External Authoriser, so that's fine.

    I do not fully understand who you are suggesting can act upon the second issue. It feels like you are implying that a Service Manager Administrator needs to do this (you mention "BPM Manager" - who is that?). To be clear, I believe the Agent at Service Desk (let's call them the Owner in Hornbill language) needs to be able to do this; or perhaps an elevated permission in that team like Team Manager or Team Leader. It should not be something the Agent needs to escalate to a systems administrator like me to do.

    I do very much agree with the words you used for the solution itself: the Owner should have a task be able "to complete the approval with one of the outcomes configured for that external approval node", as you suggest. In other words they should be able to be a proxy for that external contact. My suggestion on this was to have an Activity box added for External Authorisation showing something like this. I suggest it might be a different colour.

    image.png.4db41ec5f9fc4b38e06fa792bbcaa2d3.png

    Thank you for picking-up on this and seeing the issue and offering to resolve it.

  14. @Mary. The linked article is useful. Can youput it in the Wiki? However, that article (linked here) states "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". But I have just proven it DOES apply to Expiry Tasks... It very much does need the same calculation, right?

     

  15. I believe I have worked-out how the expiry works and I don't like it! I wonder if other users have the same experience and feel the same.

    I have a 5-day wait/expiry node:

    image.png.91b41ff79be7b0943b67144423b9f537.png

    And yet, in the log, that gap was 18 elapsed days (12 working days):

    image.thumb.png.1733f4be0ee325c19fda4c4b8ac7492b.png

    After the 5 days it moves a card on the board. I have a further node that waits 15 days before removing the card from the board; and that has now passed 15 elapsed days.

    In this Wiki article (Hornbill How To: Two Stage Closure in Service Manager - Hornbill), there is a statement "The expiry period is in working hours and will adhere to the hours configured in the "ServiceDeskDefaultCalendar"".

    We have this calendar which uses 10 hours per day 5 days per week:

    image.thumb.png.6f798ff008e56edcae7a73a7480efe07.png

    My theory is that the waiting time of a DAY, as configured in the expiry, counts as 24 HOURS but that the system only counts towards that at the rate during the hours configured for service in the calendar; in my case, 10 hours of that per working day.

    This ties-in with what we have seen:

    Configured: 5 (days in expiry setting) x 24 (hours) = 120 hours

    Experienced: 12 (working days) x 10 (hours) = 120 hours

    This is not at all intuitive and it means the administrator needs to undertake a calculation to set this each time.

    1) is there not a better way to do this?

    2) please could you update the Wiki to draw this out; perhaps an example calculation like the above? It would have saved me hours of investigation trying to understand it!

    • Like 1
×
×
  • Create New...