Steve G

Hi @Josh.F, That would suggest the device you're trying to return the details of either doesn't exist within Intune in your Azure tenant, or the user against the key in keysafe doesn't have the rights to read that device. I've just tried on our Intune and it's working fine, so I think this must be your config and/or Intune access. Could you send over a screenshot of the workflow node which is trying to get the record please? Thanks, Steve

Hi @JanS2000, Apologies, it appears I missed a step out - you need to define the output parameters against the autotask before they will appear in the End node. Clicking on this button here will allow you to add parameters to your autotasks: Cheers, Steve

It depends what you have stored in your user records to be honest, and in which fields. That automation requires one of the following to be able to identify the user in your on-premise Active Directory domain: A distinguished name An object GUID A security identifier A SAM account name If you don't have one of those stored against your Hornbill user records, then you could always extract the sAMAccountName portion on your user, using the String Utilities in the workflow. So you could first search for the location of the @ character in your user ID (you would use the current variable instead of steveg@mydomain.co.uk): Then use the Result output of that node as the To input of a Substring node, with 0 as the From input, and your User ID variable as the Input Text, as so: So in my example autotask, below: Outputs as so: Hope this helps, Steve

Hi @JanS2000, Are you able to run the following in a PowerShell command line on the target machine as defined in the job, and see if both are able to return the account details as expected? Get-ADUser -Identity yourusername@yourdomain.gov.uk And Get-ADUser -Identity yourusername I suspect that your sAMAccountName against your AD account is just yourusername, and Get-ADUser (a Microsoft cmdlet that we're using to check if the user account exists) won't see yourusername@yourdomain.gov.uk as a valid identifier. Cheers, Steve

Hi @Jeremy, I've just tested this and it's working fine, so I expect this is an issue with the refresh token, or rights on the Google account. First thing I would try would be to revoking the key in Keysafe (the revoke button, do not delete the key or you'll have to update all your workflows that use it!), then remove Hornbill from the list of approved third party apps in the relevant Google account, and then hit the connect button in your Keysafe key. Authenticate and approve as usual and you should be fine. Let me know how you get on, Steve

@Berto2002 We do have the Asset Relationship Import tool, which should do what you need. Let me know if you need any further information. Cheers, Steve

@Dave Longley Solved should have a lower-case s, as per the Zendesk API response: Totally agree with @Steve Giller though, looping every 2 minutes is a really bad idea so you need to extend that period by quite a lot. What you should really do though, is to implement a proper 2-way integration - use Zendesk triggers & an appropriate marketplace app (Zapier or the like) to make API calls back into Hornbill to update the Hornbill ticket when the Zendesk ticket is set to Solved. Steve

Hi @Art at BU, The "System.Drawing.Common" issue is a pretty new one - it appears that Microsoft have removed support for the provision of embedded icons in Teams bot solutions - without documentation. To fix this issue, if you edit the generated bot.xml file and delete the entire iconbase64 tag from the xml, save the file then perform the tar command as in @SamS's instructions above, then the solution import should go a whole lot smoother We'll get the PVA package updated on GitHub as soon as we can to remove this now-unsupported tag. Cheers, Steve

Hi @Dave Longley, You should really refer to Zendesk/Freshservice admins, but it looks like it would be possible using the Freshservice Web Request node in Fresh workflows and the Notifying External Targets feature in Zendesk to send API calls back into Hornbill. Hope this helps, Steve

Hi @Met, To answer your questions: Where there is more than one manager with the same display name, how will Hornbill decide which account to choose? Will it return an error? No, it uses the first match it finds in the cache. I can see how this would be problematic though, and will review this code in more detail to see if there's a better solution (probably an error to the log as you mentioned) Where the user already has the correct associated manager recorded against their account (because our "first time import" queries the entire sub tree and therefore includes all managers), will Hornbill still error out or will it leave the manager as the one that currently exists? No errors, but unless you specify __clear__ in the mapping for the manager then the manager against the user records will be left alone. Is there enough justification to have a second LDAP query which is used when looking up manager details? That's probably one for the community to answer Let me know if you need any more detail. Cheers, Steve

Hi @Giuseppe Iannacone, The API to get posts and comments from an activity stream (timeline) is: https://api.hornbill.com/activity/?op=activityStreamQueryItem Re: your other question, I'm not sure why the uploaded file would be corrupted. We use a similar process in our import utilities, check the code here against yours as this is working in production: https://github.com/hornbill/goLDAPUserImport/blob/master/image.go Cheers, Steve

Hey @samwoo, I can see the benefit of knowing if the second date is in the past when compared to the first, and it was a 2 second job to make the change, so I've added a new output parameter to the Get Date Difference iBridge utility to tell you if it's in the past Hope this helps, Steve

Hi @Adrian Simpkins, In your AssetTypes import config, have you set the AssetIdentifier->Entity value to match the entity where h_serial_number lives, as per the wiki documentation and the configuration example? If you're importing computer type assets and matching on h_serial_ number, the entity should be AssetsComputer as so: "AssetIdentifier": { "SourceColumn": "SystemSerialNumber", "Entity": "AssetsComputer", "EntityColumn": "h_serial_number" } Cheers, Steve

@Gavin James - SDDC This is likely due to a missing connection to O365, which is used to get the Teams session user details before retrieving the Hornbill details. This should have been done during the solution import, but can be also set either in the flow: Or in the Power Apps chatbot solution: Cheers, Steve

@Gavin James - SDDC Looks like the Power Automate flows have been imported as disabled, which I've not seen before. Do you have the correct subscription to enable premium connectors in Flow/Power Automate? If so, you could click View flow details on the affected actions, and turn the flows on: Cheers, Steve

Hi @Giuseppe Iannacone, The API you need is: https://api.hornbill.com/apps/com.hornbill.servicemanager/Questions?op=queryExec And here's an example payload: <methodCall service="apps/com.hornbill.servicemanager/Questions" method="queryExec"> <params> <queryName>getRequestQuestions</queryName> <requestId>SR00013867</requestId> <rowstart>0</rowstart> <limit>100</limit> <resultType>allData</resultType> </params> </methodCall> Cheers, Steve

@Llyr, This is now done and available on your instance: Hope this helps, Steve

Morning @Martyn Houghton, That's standard CRON behaviour I'm afraid - if DOM and DOW are provided, then it's an OR not an AND, so it'll run the scheduled job if the day of the month is between 15-21 OR the day of the week is a Wednesday. From the CRON specification: While normally the job is executed when the time/date specification fields all match the current time and date, there is one exception: if both "day of month" (field 3) and "day of week" (field 5) are restricted (not "*"), then one or both must match the current day.[3] Cheers, Steve

Hi @danec, I can see Description as an optional field in the standard ServiceNow Case form, but can't see a Customer Reference field. Is this a custom field? We should be able to add the ability to send values to custom fields if that is the case. Thanks, Steve

Hi @Berto2002, It is indeed the Object ID, as per the documentation in the workflow operation: The wiki URL you have provided is for Azure Automation, which is a different product on the Azure platform. The wiki page is actually: https://wiki.hornbill.com/index.php?title=Microsoft To get the User Object ID, you can use either of the following operations: Microsoft/Azure/Users/Get User by Email - this will search for users by emil address Microsoft/Azure/Users/Get User - this will return the user by their UPN Cheers, Steve

Hi @Berto2002, Error reporting has been made consisent across all Azure User & Group operations as part of this release: Hope this helps. Steve

Hi @Berto2002, As part of this release, we've added an operation that allows you to check if anAzure AD object ID (user or group) is a member of a specified group. Hope this helps. Cheers, Steve

Hi @Berto2002, Thanks for reporting. We'll take a look and let you know once they are consistent. Cheers, Steve

Hi @samwoo, The JSON payload schema has changed, please see this comment for more information: Cheers, Steve

Hi @Giuseppe Iannacone, Are you building and sending API calls from Jira back into Hornbill? If so, which Jira app are you using to implement this? From your error message, it appears that you're using a JSON payload, which is not officially supported by Hornbill (yet). It works, but the JSON schema description is liable to change - as it did in the most recent release of the Hornbill platform. So I expect you are sending something like the following (from Gerry's XML example above): { "methodCall": { "@service": "session", "@method": "userLogon", "params": { "userId": "admin", "password": "cGFzc3dvcmQ=" } } } When now you should be sending: { "@service": "session", "@method": "getSessionDetails", "params": { "userId": "admin", "password": "cGFzc3dvcmQ=" } } Note the lack of methodCall property in the second snippet. Cheers, Steve