Victor

@DougA table permissions can be configured on roles.... what roles you have associated to these users? I am quite sure you won't supposed to see this type of error...it suggests a role is broken (or more)....

@derekgreen This might explain it then... it is quite possibly the BP is not aware of the analyst being changed so it won't know it needs to fire the notification email... and most likely the BP has gone past the stage where the notification is sent... So, I would advise to use the notification system which is independent of BP... this way notifications will fire whenever the analyst is assigned/changed... EDIT: forgot to mention, just to avoid confusion, notification type needs to be "email-only" or "both"...to have the email triggered...

Next planned SM build to be deployed is currently 954..but this can change We usually refer to next build/update in live instances as any build "greater" than current... so in this case the timeline search feature will be available in SM build > 944. When James advised on the next update the current build at that time was 946, however this changed since... so best to use "greater" than, to avoid number confusion

@derekgreen do you know (are you aware) how this notification is configured in your instance? I mean do you use the BP to send an email notification to the analyst upon assignment or you use Service Manager notification system (notification application settings)? Or a combination of both?

@Sonali thsi is following my investigation: "Any Software Request" catalog item belongs to "Personal Computing Services" service. This catalog item is used to raise an SR and currently configured to use "standard_software_request_pg_v1" progressive capture. This ProCap is configured to ask for request category in the last screen/step/form: And this is how it look on the service portal: "Raise An Incident" catalog item belongs to "Core Gaming" service. This catalog item is used to raise an IN and currently configured to use "generic incident process" progressive capture. This ProCap is not currently configured to ask for request category at any stage: And this is how it appears on service portal: So in conclusion, from what I can see, all/everything behaves as configured... unless I am missing something...

@Awalker no worries, like I said I know what the error is and will ask dev to make sure we cater for in case it might happen again...

@TrishaRush just had a quick look at this functionality, I was a bit wrong (or incomplete) in my statement, apologies What should happen is that when you click on "Make Copy", it creates the copy and activities straight away... So following your example, you are currently viewing "Test - Incidents raised YESTERDAY"... when you click on "Make a copy..." the view title changes (or should change) to "Copy - Test - Incidents raised YESTERDAY". You should now be able to make whatever changes you need in teh copy (if any needed) and click on "Save" button. At this point you should have the copy in your view list...

@Awalker try with the original steps... by the way I know what the error is and I think dev team can fix this, I just wanted to make sure I understand the circumstances on which this occurs...

@Melissa Gurney no worries, we'll raise an incident now and update you as soon as possible

@Sonali what is the name of the catalog item? (the CI - catalog item is linked to a service this is why I asked about the service but the catalog item name should suffice) In any case, as far as I am aware, when using services portal (which is the analyst's portal) the analyst (or the user) does see (and is supposed to see) the "Request Category" form... it could be different for basic users or users with no Service Manager rights... but I need to check this in more detail.. this is why I need the name of the CI so I can have a look at the overall configuration...

@TrishaRush as far as I know it creates the copy is just you don't get a visual feedback on the copy action...have another look in the views list, is there a copy of the view?

@Sonali when you tested this, what service you used and what catalog items for incidents and service requests?

@Sonali what portal? services.hornbill.com... or customer.hornbill.com... ?

@Melissa Gurney whichever you prefer Raising a request gives you a reference if you want to track it... but here is fine also since I am trolling the forums anyway

@Melissa Gurney if you can gather couple of examples I can have a look and see if I can find anything...

@DeadMeatGF it will (sort of) auto close when the tasks expires... BP will follow the "Expired" branch which closes the request... So the general idea was that you create a human task with X days expiration time.... task has 2 outcomes "Close" and "Reopen". On "Close" it will happen basically the same as when the task would expire which is to set request status to closed (and trigger the whole close request flowcode). If the analyst selects "Reopen" then the request status is changed to open and loops back on "resolution"... @Melissa Gurney if nothing changed (in your support internal process) since we discussed the BP then yes, it looks correctly configured

@DeadMeatGF @Melissa Gurney the task should be human... to cater for a request reopening... and is how an analyst should reopen a request if necessary. The "automatic closure" node will not cater for any request status it will proceed with closure regardless of what happens to the request. The way it works is that it creates a BP "close request" event on that specific date/time. When the date/time is reached the event triggers, regardless of the request condition/status... So, you should use the automatic closure only when you are sure teh request should be closed regardless in that specific time frame...

@Awalker looking into this...don't think you done something incorrectly, it seems to be an issue on our side... EDIT: the issue seems to be here somewhere (screenshot)... again, nothing wrong on your side but it seems the BP is having a hissy fit with the timeline updates... from the task completion and the second timeline update ("Implemented" one). May I ask, if possible, to do a test as follows: with current process raise a test CR and progress all the way to this... I think the issue should replicate at this stage; amend the process and temporarily remove the "Update Timeline - Implemented" node (eventually create a backup of current process to revert back to it); with amended process raise another test CR and progress it... I'm curious if the issue will occur again.

@Martyn Houghton good to hear your thoughts on this The "Close after time period" node creates a BPM event with associated timers. This means that when the timer is reached, the request will be closed. Currently there is no option to "cancel" this type of timers... meaning once the close BP event is created the request will close regardless of any actions on it... So, with the new functionality to cater for reopenings, such BP events will be adjusted accordingly (either removed or changed). Request timers are independent of request actions... until recently, the resolve request also stopped the resolve/fix timer but this is no longer the case. To stop the timer you will need to have a "stop timer" node. Therefore you can trigger this when you think is needed and meanwhile have any request status... including close if you so need ... but not "Canceled". However once the timer is stopped, it can't be restarted. Not with this functionality. As far as I know there are some challenges around this design (return to previous stage) so can't say if and how this will be done... but not at the moment. This thread is discussing the same idea: I must have missed this thread, sorry about this. Would you mind detailing on what you mean by this?

Ermmm... might have missed one branch ... EDIT: ...or not... but.. on 151, how come you have all these the "Authorisation To Proceed [Normal]" tasks?... I don't see where all these tasks were created, the BP only supposed to create these 5 "Authorisation To Proceed [Normal Change]" tasks....

@Awalker I made a change to "CCG_Change Request_Non Elevated Access" process which I think caters for these scenarios... Give it a try, I can only hope the force is strong with me as well... (*jedi waving hand) ... Your process works now...

@Awalker so, to make sure I understand this correctly, for example: Scenario A: Han Solo is a member of the change management team, one of the persons able to do the authorisation to proceed. Han raises a change request where he is the customer on the request. In this scenario, although he is a member of the change team, Han should not be able to authorise this change. (although he always seems to get around things funny enough); Scenario B: Darth Vader is NOT a member of the change management team. Vader raises a change request where he is the customer on the request. In this scenario any member of the change management team (e.g. Han, Leia, etc.) should be able to authorise teh change as Vader has nothing to do with this team (although he might be able to do anything he wants, he knows the force quite well). Jokes aside, I hope this is how the process works (or should work) for you...

@Claire Holtham can you give us some examples of these requests so we can establish the scenarios where this worked/not worked? Thanks!

@Awalker ah, I see, wel... theoretically should be possible, I'll have a look at few examples in your instance and see if I can come up with some BP rules to cater for your scenario...

Hi all Foremost I wish to say many thanks to all community members for your valuable contribution to the forums This thread is an initiative to introduce you in the world of our Service Manager development and you an insight of the wonderful projects and features they are working on. This is thought to be a regular post which will present various new planned things, what and how we want to do and give you a chance to get acquainted with future "stuff" and obviously to discuss them. We already have a Service Manager roadmap, accessible on customer portal which shows you everything in plan for the next 90 days, which I say is great. These diary posts will give give you a chance to find more in depth information about things on roadmap or even outside of it and, most importantly, you have the opportunity to feedback on it which I am sure not only development will appreciate but all Hornbill team and ultimately would allow us deliver an even better solution for you. But enough with introductions, let's get to the juicy stuff Today we will cover a much coveted topic raise and discussed on many occasions: the disconnection between BP and manual interaction on requests - more specifically allow the BP to handle two stage closures and reopen! I know, right? We all want it!!! In any case I know I do So, good news, we are building it! And this is how we thought of it in a nutshell: provide a new BPM automated task that will wait for a status change and then use the new status as an output for a decision and improve the existing close after time period BPM automated task to support requests that have been reopened Now that would be really nice I say! How this would work then? This is what we think of: A new BPM operation called "Suspend and wait for Status Change" which allows the BPM designer to do the following: Waits for any change in the status; The status that is changed to becomes the output so that a decision node can use this to branch based on the status that it changed to; Amend the "Close after time period" which will only close resolved requests and will delete timers once they're no longer required; If the request has been re-opened the closure timer is also deleted. This was thought primarily to handle requests being actioned (e.g. reopened) by a customer on the portal but certainly can be put to good use in other scenarios as well. Happy to hear (well, actually read) your thoughts on this! Before anyone gets too hyped on this, there is no ETA when this functionality would be available yet. I hope this is one (of many to come) insights into what we have planned for you and I promise I will try and make it as often as possible and more detailed!