Victor

@samwoo it is by design... the whole routing, logging, etc. happens in the AR context so you will have timeline entries in that respective context... Maybe have something like "request logged by AR on behalf of contact X..."

@DeadMeatGF see... now you talking foreign languages to me ... (not entirely but don't know the answer I'm afraid) ... Maybe, one of the devs can have a look and advise...

@derekgreen have a pint for Hornbill as well ... (like a reason is needed to consume unholy amounts of alcohol...) ... I didn't say anything...

@Adrian Hodgson I am not entirely sure if is something that is not correctly configured (on your side or in Hornbill), so a shared call or paid session would not help... As you are subscribed to a support plan, I will log an incident on your behalf. I will then advise our colleagues from dev team who implemented SAML protocol of the issues you are facing to see if maybe Hornbill is not redirecting to the correct idp when using guest realm...

@DeadMeatGF right, after a bit of digging, I found out what happened (next would be to see how and why)... is related to my thought above, something with the list names... So, first thing I checked if by any chance the BP went via the "site = Broomfield" branch in the first decision node. It did not... the BP correctly went through all decision nodes up to "site = Ilkeston". So the site on request and decision node configuration is not the issue here, all is correct so far. Next I looked a the "add to board" node, below is an extract of the configuration from this node: (I posted this as I know you are quite technical but if it does not make sense I'm happy to explain) So, the board is correct (id = 30 is the id for Facilities Caretaking board) however the next bit, the list, seems to be incorrect... as you can see the BP definition has the list name as "Ilkeston Campus" instead of just "Ilkeston"... which is the actual name of the list... (this is actually the bit I am now trying to figure out). Moving next, all behaves as designed, meaning if the list name in the BP definition does not match any existing list from the respective board (it doesn't because "Ilkeston Campus" != "Ilkeston"), then the flowcode will designate as list the first list defined in that board, which is Broomfield. And this is how this request ended on that list...

@derekgreen all is well when it ends...well ... Have a fantastic weekend!

@DeadMeatGF was wondering if you changed the name of the list from "Ilkeston Campus" to "Ilkeston" at any point?

@DeadMeatGF don't worry about the exact time, approx. is sufficient... I'll have alook and see if I can find anything obvious...

@derekgreen not really...but... notifications to self? Why would you need a notification when you are the one raising and assigning the request?? ... this is how the system is thinking Try and raise a request and assign to someone else..then ask that analyst to check if they received the notification... system notifications are not designed to "self-notify"

@DeadMeatGF what is the request reference where you noticed this? Also, can you give me an approx. time (date) when the request was moved to the incorrect board?

@Adrian Hodgson just to confirm, what URL you (your guests/customers actually) are using to access the portal? Is it https://customer.hornbill.com/orcinternational or https://service.hornbill.com/orcinternational?

@TrishaRush just to confirm, this is how the view and copy functionality should work: For example, the existing view named "Test": When you click "Make a copy..." button, this should be displayed (below screenshot). At this point the copy should also be available in the view list... We need to understand the circumstances when this is not working to be able to find if there is a defect here

@Darren Rose maybe something like this? (if I understand your struggle correctly...

@Sonali currently analysis which have the right to update requests can update requests even after the request was closed. There are no settings that can be enabled to prevent this. The above settings are intended to prevent automatic updates on closed requests which analysts might miss since closed requests are not visible in the active queue....

Oh dear ... Just wanted to make sure I don't create the wrong expectations

Just need to remind that dev diaries discuss potential features that is on our dev team attention... It also means that IF the feature is introduced at any point it might not have all the expected complexity and depth discussed (for example there might be potential technical challenges which could prevent a certain level of complexity at that point)... it might be subject to a partial deployment of functionality, or different functionality. Also there is a possibility (not likely though) that a certain feature we think of might get scrapped all together... The diary has been thought to give you an idea on what (and how) we are thinking of doing...to gather your thoughts (if any) and feedback and to give you an insight on future plans! Please don't take these diaries as a commitment from us to deliver a certain feature You should use the 90 day roadmap available on portal for this purpose

@Keith yes (to answer your last question), the new functionality will (better said should) cater for existence of BP events for request closure and amend them if the respective request status changes to "open" for example... So the way it should work is like this: request is logged and progressed to resolution stage; once resolved the BP creates an auto-closure event using "Close after time period" node; next step in the BP wouldn be the new "Suspend and wait for Status Change" node - BP suspends at this point. When BP resumes you can have a decision node to check for the "new" status and branch the process as required. If the status changes from "resolved" to "open", then the auto-closure BP event created before is removed.

@Sonali the settings you highlighted are to prevent updates on closed requests (IN and SR) which are made via email by the auto responder (routing rules) functionality. However this is how they should look like: If this is not how they are displayed, perhaps a refresh or log off/log on would sort out the display issue?

@Sonali you can prevent a ticket (request) being resolved if it has open tasks (activities). This is managed via an app setting: webapp.view.ITSM.serviceDesk.requests.resolve.denyWithOpenActivities I'm afraid there is no current functionality to prevent a request being closed if it has active tasks - e.g. tasks that might have been created after the request was resolved...

@Keith this is why the dev diary initiative...

@Keith not that I am aware... about the custom statuses... thought to be the topic to cover in next dev diary...

@derekgreen I should have mentioned that if you enable system notifications the BP would need to be amended to remove the analyst notification node... unless you want them to receive two notifications... sorry

@DeadMeatGF for task reason you would use this: &[functions.getTaskParams("<task_id>").completionDetails] <task_id> will get replaced with the task id as defined in the BP XML file... In case you wonder why is that there... you would need to use the Variable Picker for this... EDIT: just noticed you are aware of the <task_ID> ...

@derekgreen ermm... not for notifications,no... notifications use an "internal direct email" method which bypass the mailboxes... so you don't need to worry about analysts mailbox rights when configuring notifications...

@all - To confirm, the new functionality - the ability to search request timelines from global search - is not included in the latest SM build (954) deployed to live instances this morning. Most likely it will be introduced in the next update. As James suggested, we need to overcome some performance challenges before we can safely make this available.