CraigP

It's been brought to my attention a user in a particular OU hasn't been added to Hornbill. Upon investigation I can see that an instance of the corresponding Data Import Configuration appears be stuck in the "Started" status (having started on 08/01/24). This has resulted in new attempts to run this configuration to fail to run and return the error - "Unable to run import, a provious import is still running" (yes, "previous" is spelt like that in the message). Is there anyway that I can force the stuck instance to stop?

Thank you for highlighting the separate settings for Summary and Description, but I am referring to the custom fields (e.g. custom_e) mapped with the capture form. Essentially I'm looking for the copied request to have the same custom field values as the original request when it was first created (i.e. custom fields that were mapped by the capture form remain, but any field values that got set/amended as the request progressed will not be copied). So my understanding then is no, custom fields mapped by the original Capture Form will not be mapped to the new request if I turn the app.request.copy.customfields setting off. In which case I'd like to be able to clear custom fields in BPM. I have looked into this before but I was left under the impression it wasn't possible? Is there any way to do this that I might have missed? I see this was recently raised again for custom Date Fields, but no response at time of writing.

Thanks for the swift reply Steven! If I turn this off, will the mapped custom fields from the original capture form still be mapped to the newly created request?

Is there a way to avoid copying across the custom fields when using the Copy Request functionality? Ideally any custom fields mapped by the Capture Form should still be reset to those values on the new request, but any other fields (set by BPM or manually) should not copy across. Alternatively, if this is not possible, have there been any updates to allow nullifying or emptying custom fields within the BPM? I looked into this a long time ago but strangely there seemed to be no BPM functionality to do so at the time. One would expect if you set a field to manual and leave the value blank, then it should at least put an empty value in that field.

Thank you for the suggestion Steve, but this doesn't address the larger issue in that I'm trying to bring it to Hornbill's attention that this API (which is one of the officially supported, public facing APIs) seemingly isn't working 100% correctly. I'd be happy to know if I'm just entering something wrong rather than it being a bug with the API, but either way please can this be confirmed? I appreciate if you're the person to be able to answer this, but if so I'd very much appreciate this being passed on to an appropriate colleague. I see the Import Tool is seemingly still using data:entityUpdateRecord. I'm curious to know what will happen with these tools if access to these APIs is removed? Will the required APIs be configured somehow to only be accessible with the tools and not for general use by Hornbill customers?

I've been asked to mass update some asset information in our CMDB and following the information about the future of Hornbill APIs in this thread, I'm again looking to use the "correct" API updateAsset2 rather than entityUpdateRecord. However the former is still proving to be unreliable for updating asset information (having received no response above, I carried on using entityUpdateRecord to update "MAC Address" and "Network IP Address" fields I was having trouble with previously). Despite updateAsset2 now being on the list of "customer-facing APIs" I'm still finding the same issue I highlighted above (i.e. the JSON syntax appears to only accept the display name of the field rather than the database name, but if the display name has a space in it, it doesn't seem to process it). The fields I'm looking to update this time are Additional properties "OS Description", "OS Version" and "Network Windows Domain". To test my hypothesis about the spaces in the display names, I added an entry for "Model" in the middle of the JSON string and it successfully updated the Model field but not the others. Even if I'm wrong about the spaces, this should at least rule out there being any issue with the JSON string, API key permissions etc. Please can someone confirm whether there is an issue with updateAsset2 updating certain fields, or highlight if there is anything I'm doing incorrectly. I have added an example JSON string I'm providing the AdditionalProperties parameter below: [ { "name": "OS Description", "value": "OS Description Example" }, { "name": "OS Version", "value": "OS Version Example" }, { "name": "Network Windows Domain", "value": "Network Windows Domain Example" } ] On a side note, will there be some kind of "Get Asset" API added to the public facing APIs? I've been given a list of assets to update by asset name, so I need a way to retrieve the Asset ID to be able to feed it to UpdateAsset2. For now I will continue to use getAssetsFiltered for this, but I see it is not on the list.

Does anyone know what the syntax would be to put something like "6 months ago" into the custom criteria please?

Thanks Steve. I've done a bit of testing and an Autotask with that automation seems to do the trick! Is there a reason that the in-app option to resolve linked requests doesn't list on-hold requests while the Resolve Linked Requests automation will go ahead and resolve them? Just want to make sure circumventing the in-app way of doing this isn't going to cause an issue elsewhere. Another thing I am a little concerned about is that while testing how it interacted with linked requests of various statuses, I noticed that a cancelled linked request still gets marked as resolved when using the Autotask. Is this intentional, and is there any way to avoid this? I'm not sure I understand in what situation you would want to mark a previously cancelled request as resolved.

I can confirm getUserProfileAssets seems to be working again for us. Thanks for getting it sorted!

I tried enabling the "Resolve" option under the "On Hold settings" but this does not seem to impact the ability to resolve linked requests that are on-hold. I've taken Martyn's response into consideration with my own scripted solution for doing this (gets all requests linked to the "parent", resolves any that are currently open, and sets any that are on-hold to open first before resolving them a few seconds later). This does the job but ideally we need to have the option be able to resolve all linked requests (including on-hold) in the Service Manager app without the need for someone like me to run an external script. Can someone please confirm if this can be added, and if not, let me know the reason why so I can report back to my colleage?

Thanks for the info Gerry. We use getUserProfileAssets too. I'm troubleshooting a different issue this morning and noticed this doesn't seem to be working anymore (it's returning "Uncaught TypeError: Cannot read property 'length' of undefined"). Happy to replace it with an API that is deemed more appropriate to be customer facing, but the Asset page seems to be quite sparce in this regard. What is the suggested way to script the retrieval of a user's assigned assets?

I noticed "Progressive Capture Customer Search form - Option to include archived users {CH00179697}" on the latest Service Manager update. Where can I find this option please? Can it be enabled per service or as granular as per catalog item? Also this implies to me that it is only for selecting customers, and not for general user lookup fields in capture forms/capture task fields. If that is the case, is it possible to enable for user lookup fields too?

Thanks James. I suspected this may be the case, but it seemed odd that attempting to delete generates a popup message while renaming doesn't? Also, as far as I could tell there weren't any active workflows using the workflow/BPM in question (there were only a handful of test ones I raised a while back and cancelled, and one completed one). I even went back and deleted all the cancelled/completed instances in the "Manage Executed Workflows" section, and it still didn't rename correctly. I've now copied it with the name I wanted, and deleted the original. As Andrew has stated, if it was in use, then I would have expected it to prevent me from deleting it, so it feels like there is something odd going on.

Is anyone else having trouble renaming workflows / business processes? I'm finding when I rename a workflow, it will appear to do it, but then when I refresh the page it reverts back.

I had one colleague report to me earlier that the category list was empty when they were trying to fill out our Change Request form. Seemed okay when I filled out the form on my side, but it would be useful to know why this may be happening if it wasn't just a one off blip. I haven't had confirmation from my colleague that they have got it to work yet.

Fantastic, exactly what I was looking for, thanks James! It does seem to bring up a "The node is referencing a context variable that does not exist" warning when validating the process, but it worked as intended once published anyway.

Is the user ID of the person running an Autotask stored anywhere that can be accessed from the Autotask workflow? I was hoping that there would be some kind of accessible "session" variables like there are for Capture Forms, or at least that the "Auto" option for the User ID on HB Automations like "Get User Details" would use the ID of the person running the Autotask, but this does not appear to be the case.

Thanks Steve. I see that the settings I had previously amended were still amended in this section, so I must have amended the wrong ones. I see there are multiple settings for these, it seems the second one was the one I was looking for. Out of curiosity, do you know what part of Hornbill each of these affect? guest.com.hornbill.servicemanager.portals.portal.home.requestView.details.resolve.(working / broken) guest.com.hornbill.servicemanager.portals.servicePortal.home.requestView.details.resolve.(working / broken) ui.app.com.hornbill.servicemanager.selfservice.(closeRequest / reopenRequest) user.view.selfservice.resolve.(working / broken)

I am still interested in being able to change the text on these buttons, please can I have information about how to do so if the application settings have been moved/renamed/removed?

It looks to me like you're assigning a task to a variable, and that variable contains the request ID rather than the ID of the user/group you wish to assign to.

I updated the wording/translation on these earlier this year, but have noticed that they have reverted back to the original wording. I believe I had previously changed the following system settings, but I can't seem to find them anymore, were they removed? guest.com.hornbill.servicemanager.portals.portal.home.requestView.details.resolve.working guest.com.hornbill.servicemanager.portals.portal.home.requestView.details.resolve.broken If so, how do I go about amending these buttons again? We don't feel that they are suitably named for Service Requests (or even a lot of incidents to be honest!)

Glad to be able to help. I've done a little more testing and found that the assignment node doesn't fail if you give it a team that doesn't support the Service. In fact, the way "default teams" currently work in Hornbill (if no team is provided to the assignment node, it defaults to the user's first team as it appears alphabetically) seems to also go ahead and assign the team even if that team doesn't support the service. I'm not 100% certain that it does not cause hidden issues elsewhere, but from my limited testing it seems the owner can still see the call while anyone else in that team (who doesn't support the service under another team) can't see it. The assignment tab's dropdown is blank, but the team field in the database table has the assigned team populated.

Interesting, we appear to have that set to "on" already, but it does not seem to cause archived users to appear in a user lookup on a capture form. Curious to know what areas of Hornbill it does impact.

To my knowledge this isn't available, but it's been a while since I've looked at it. It would be useful because this has caused a headache for some processes, specifically our "Return to Work" process where obviously the account has been disabled and is now archived in Hornbill, and the entire point of the request is to be able to select an archived account to be re-instated.

Yes, been there! Just to confirm, I've been working on raising requests with the API recently and have successfully included the questionFieldMap parameter. I haven't tested yours exactly, but this JSON format seems to match what I've used, so I can only assume there must be something up with how you're populating e,h,i and o. { "h_custom_e":"<REDACTED>", "h_custom_h":"<REDACTED>", "h_custom_i":"<REDACTED>", "h_custom_o":"<REDACTED>", "h_custom_21":"2023-01-09 00:00:00" }