Victor

@Jeremy no ETA but I expect the update to take place this week or early next week at the latest.

@SJEaton you cannot have a "wait for linked request resolution", the functionality is not there. What you have above is a simple wait for resolution on that particular request, not the linked one. If the main goal is to have the "parent/main" request active and reacting to events on the "child" requests, then in theory, you can achieve this in different ways. First, it would be problematic to achieve the "HUD update" in the parent request based on events on the linked requests. The only way I can think of is to make use of the "Wait for Request Update" in the parent request in a somewhat semi-permanent state. The linked requests will push an update on the parent request. Based on this event you can drive the workflow on the main request to perform various actions. I say this is problematic due to the semi-permanent suspend state of the main requests which basically "blocks" the main request at that stage, at least until all linked requests have been progressed to a certain stage (e.g. resolved). The workflow in the main request will also have to cater for updates other than the ones coming from linked requests (if there are any). Another idea would be to make use of custom fields on main requests that will be updated from linked requests. You can have each linked request "associated" to a custom field in main request to reflect the stage of that linked request. You can then make the custom field visible in the main request details section, thus mimicking the HUD. This solution would require pushing the main request data (e.g. reference) into the linked request so the linked request knows where and what to update in the main request. Another solution, which would be perhaps the least complex would be to make use of human tasks. For each linked request you would have a human task in the main request. The human task will be completed once the corresponding linked request has been progressed to a certain stage (e.g. resolved). The main downside of this approach is the human interaction required to action on the tasks. EDIT: I have also split this conversation from the other thread as it is now discussing something different than what that thread was discussing.

@Jeremy it is a known issue. Will be fixed in the next platform update.

Fixed in SM build 2690 Settings for Pause Until Date/Time and Reason Required were not available within global sub-status configuration forms {PM00172830}

@Paul Alexander not that I am aware. Please if you raise a support request, do not put FAO Victor with the summary, even if there is distinct possibility I will perform the necessary. Looking back I see I did advise James as such but I have come since to regret this type of advice

@danec yes, there should be. However your subscription period had an incorrect date so it appeared as not subscribed to the success plan. I have corrected this now, give it 10-15 min and try again, it should have all options available.

Also: Once set it will use it by default when navigating to activities.

@danec As a Premier Success customer you can always request for an answer to be expedited on a forum post.

@SJEaton Depends... "Wait For Linked Request Resolution"... what is that? Can you screenshot the node setup?

@Dave Woodhead right, I would advise raising a support request, we need to have a look at the timeline entry in the user context to understand a bit more of what is happening there.

@BobbyB in general, an expired task in itself does not prevent a request from progressing. But it depends on how the workflow associated with the request is designed to function. I would advise checking this scenario with the business process designer for that particular workflow.

@Dave Woodhead it does not. Request status has nothing to do with visibility of timeline entries. For the timeline entries that are not visible for the user, can you check what type of visibility they have?

@BobbyB sorry, perhaps I am missing something. The task is expired, it should not be in anyone's activity list...

@BobbyB umm...deleting or changing... wwwwhy?

@lokent have a look at the documentation for mapping custom fields (link below). Any field that is if type DATETIME can be formatted for localtime and only this type of fields can be formatted with localtime. https://wiki.hornbill.com/index.php?title=Mapping_Fields_from_Customised_Forms

@Jeremy this line means the message was relayed to the "smtpserver" and it is now outside Hornbill control. The part that Hornbill was responsible for, which is relaying the message to the relevant "smtpserver", has been completed successfully. Perhaps worth looking at the relaying server or further down in the relaying path.

@Jeremy what does the Delivery Status say/logs after resend?

Just to clarify for future reference: Tables available for selection when designing reports are NOT filtered by app. ALL tables will be available for selection regardless of the app context when in admin view. Reports however are filtered by app and the reports displayed in "Reporting" in admin tool depend on app context when in admin view. A report created via "Platform Configuration -> Reporting" will only be visible while in "Platform Configuration" and a report created via "Service Manager -> Reporting" will only be visible while in "Service Manager"

@samwoo I always worry...

@samwoo https://www.hornbill.com/support/

@JAquino I'll send you a PM (private message) to progress this.

@Geoff Soper As per above the reports are grouped by app. In the above screenshot, where exactly you are in admin when viewing those reports? Platform Configuration? Service Manager? or other app?

@Alisha may I ask if possible for a screenshot with this issue? Please obfuscate or remove any sensitive/confidential data from this screenshot. We will raise a support request to investigate the issues you reported.

Tables available for selection when creating reports are not specific to app context. All tables are available in the list regardless of where you are in the navigation menu (e.g. Platform Configuration, Service Manager, etc.). h_itsm_requests is not available with this name in Reports (h_itsm_requests is only in DB Direct), you are looking for the "Requests" table: While app context does not matter when it comes to available tables when designing a report, it will matter in regards to where the report will reside. For example, if you create a report while in Service Manager - so using the "Reporting" admin option from Service Manager section - then the report created will only be visible and accessible from this reporting section and not from other reporting sections (e.g. reporting section from Platform Configuration or another app).

@Martyn Houghton when it comes to API params, display name is not necessarily the param name, for example on the BP param. But yes, it needs to be the ID which is the hyphenated name.