Steve Giller

It sounds like you're using an external QR code reader to scan the code, you need to scan from within the app. Did you watch the video on the wiki page? This has a very good step by step procedure.

If you're using SSO to sign in to Hornbill, you will need to register the device, not sign into it.

This sounds like a job for ... "Timesheet Manager" ... Reporting on updates should be possible, unfortunately not my area of expertise, but as an update can be as simple as applying a Customer's email, or as complicated as writing up a 3 hour remote session with a Customer this may not give you useful information. Timesheet Manager allows Time Spent to be recorded against any action and should give a much better view not only of how much time is being spent on Requests, but also what areas are most time-consuming.

This setting can certainly be changed, but this is the email template that is used, not the setting for whether emails are sent or not. If you review the values for the settings that begin: guest.app.requests.notification.notificationType these can be set to hornbill-only, email-only, both, or none, and the guest.app.requests.notification.allowUserDefinedNotificationType setting determines whether analysts can alter their personal notification settings.

I've tested this to confirm what I thought was the case, and in- is always the upper connector.

A noted on the wiki page:

This is the intended behaviour. If you have selected a date, and then change your answer to "No" but subsequently realise the answer is "Yes" after all, then the assumption is that the date you gave was also correct first time. If not you can correct it.

@Adrian Simpkins It will certainly be explored, the Devs have noted it and it may be useful for ad-hoc exports. My angle is more that if the export is gathering the same information (as in the Analyst's Requests example) the afternoon taken setting up a configurable report will return on the time/effort fairly swiftly.

I'll get my personal bug-bear out of the way - exporting the Request List View is not a report. The View is ... a View, it's designed as a view, something to be looked at on screen. Thinking of an export of this View as a report immediately generates inflated expectations of what you can do with it. Which goes back to the original question: What is exporting the list achieving for you? Why does having the Request List in an Excel spreadsheet assist the Users, and more importantly, how frequently must these "one-off" exports be occurring to make it a frustration? (I'd argue this is a long way from one-off ...) A quick example: A report with a User Input for the Analyst would achieve that, including allowing more data than the Request List is limited to, and would be in an agreed and consistent format.

What is exporting the list achieving for you? There is probably a better way of doing this - the export function is designed around infrequent ad-hoc exports of the View and if you're doing this on a regular basis then the Reporting functionality is likely to be a better method.

What happens if you update the Timeline with &[functions.getTaskAnswers("task-8e8b6c91").field_1]?

@Jeremy If it can't be automated in the BPM, how do you envisage it being automated by a snippet? The way the original description reads, you're asking that if Snippet X is selected for a Request Closure, then Category A is applied, and if Snippet Y is selected for a Request Closure, then Category B is applied, etc. Checking for content unique to Snippet X in the BPM and applying Category A would do exactly that. There must be part of the requirement we are not understanding here, can you elaborate?

I believe this is one of the reasons Via nodes were introduced.

The Entity Explorer under the Service Manager Admin section will have all of the relationships. You will also be able to check the Data Types for the various fields here, too.

You can ask ... I've tagged this as an Enhancement for you.

Anything on the active timeline can be viewed via Admin -> Hornbill Solution Centre -> Roadmap Library

If all Requests on all Services automatically send the request then it should be this simple. Combined with the database info from James you should be able to achieve what you need.

While this is the case, please ensure you keep the dryrun flag set to true. AssetGenericFieldMapping are the values that apply to all assets, these are stored in the h_cmdb_assets table and are discussed here. AssetTypeFieldMapping are specific to the asset type, these are stored in the various h_cmdb_assets_basic_[type] tables and are discussed here. Sample JSON configurations are also given on the wiki page Have you created an Asset Type of BASE? This is not a default Asset Type, so if not the import will not work.

It's probably worth adding your comments to in order to prevent dilution.

That's correct, you would need to be viewing an Asset Type that has a Serial Number.

Yes, with the caveat that you need to be in a view that has the Serial Number displayed.

It's possible that you need to specify the Catalog Item on the Routing Rule Template - without having sight of your Service Portfolio I can't be sure.

The solution provided by @Bob Dickinson is still the advised method.

This suggests to me that the Routing Rules are working fine, it's the raising of the Requests that is failing. Once you have taken the troubleshooting steps provided by Victor, if these do not resolve the problem I would check the Routing Rule Template and the Service/CI that it invokes.

Development have clarified that it's not security that prevents the update content being presented, but practical considerations as the content could (in theory) be unlimited. The aim of the webhook is to provide enough information to use additional methods (e.g. the Web Services API) to connect to Hornbill and collect any additional information that is required.