Victor

@SJEaton I have sent you a PM... don't think you can share a custom field across services (thinking on the table structure) ... but I might be wrong...

@Gary@ADL can you describe the actions performed so I can understand the context of the BP... (I think the logic of the process might be slightly flawed but don't quote me on this )...

@dconagh your metadata file is not public so Hornbill instance can't access it hence the empty XML message. You need to manually process this file. Open the URL in a browser, it should display the XML file content. Copy this and use the other option to process metadata in Hornbill (XML file)...

@Gary@ADL haven't looked in detail but I did spot the custom expression is using an incorrect value for status... you have typed in "resolved" but this is not the value stored in the database... the correct value for each status is as follows: Request Status: Open - Static Value: status.open Request Status: On-Hold - Static Value: status.onhold Request Status: Resolved - Static Value: status.resolved Request Status: Closed - Static Value: status.closed Request Status: Cancelled - Static Value: status.cancelled Another alternative would be to keep current static value (e.g. resolved) but use "contains" for evaluation rather than an exact match: "=="

@shamaila.yousaf your suggestions will be certainly considered by our product managers and developers. I was curious if there is any specific reason why requests are manually added to the board, is this simply because a BP is not yet in place or the BP does not have the functionality to achieve what you need?

@SJEaton yes, this was my thought... So if the new employee start date is, let's say 01/10/2017, the analyst will put the request on hold until 01/10/2017. The BP at this point should be in a suspend state, wait for the request to come off hold. On 01/10 the request comes automatically off hold, at which point the BP will resume and continue with the next node which should be the email node...

@SJEaton when this was discussed internally, one of the suggestions was to have the request put on hold manually, by an analyst, until the Start Date. During this time the BP would be in a suspended state, waiting for the request to come off hold. When it does, the BP can send the email... would this work for you until we can find a better solution for this?

@colind have a look here: It could be that your current BP version, the one with "hornbill" address, has not been published, the active version is still the one with "john" address...

Even more happy days!

@colind did you click on the ∑ sign to open the variable picker menu? When you click on it, this menu should open, where you can select the variable for the desired node/flowcode (e.g. Get Request Details)

@derekgreen it seems your colleague does not have access to boards...this is where the BP failed, when it tried to move the change request to a board... the user progressing the change at this stage needs to have "My Boards" role... EDIT: Further investigation reveals the above statement is not true and the issue was caused by a product defect.

Yay! Happy days! ... and It's Friday!!!

@chrisnutt you would need to set the notification mailbox too... this application setting:

@chrisnutt haven't forgotten about this, still looking into it, I'll post an update bit later on...

@chrisnutt do you have a (recent) request reference where the issue occurred? I can use this info to track the code execution in the logs and see what happened when notification supposedly run...

More happy days!

@David Wilson you're right, sorry, got confused as P1 email also uses "New Request Confirmation" template so I thought is that one... right, so, more thorough look and it seems the BP is actually in suspend state at second node, "Wait for Incident Owner"... if you assign an owner on IN00000098 (which currently doesn't have an owner), does the BP progress to the second email?

@David Wilson actually I did, apologies got carried away with work and forgot to reply ... I don't see any fault in the BP and on IN00000098 , I can see the email notification was sent as configured in the BP (as per the last timeline entry)...

Happy days

@SJEaton found the problem... the "Customer" portal was missing a security setting (a role) which I added: "Service Manager Authorised Guest" (screenshot). This role is required to have the services displayed on the portal. @chrisnutt I think you are missing the role as well... can you follow the screenshot and add the missing role and see if the issue still persists...

@David Wilson I assume you tried this on a tests request...can you tell me the reference for it, I'll have a look and see if I can spot anything obvious...

@Michael Sharp @Paul Alexander @nasimg @Alex8000 the brief downtime was caused by a minor infrastructure change that due to an error it affected live instances for about 2-3 min, as it was corrected almost immediately but our infrastructure team. Apologies for inconveniences caused.

@Ehsan might be on to something on why the error occurs

@Dan Munns could be because you have the change subs status on update setting enabled but you don't have sub statuses for change request catalog items?

@Sean Burke click on navigation menu - Service Manager - Services (screenshot). Edit the service you need and you will find the options there. You can find more info about service details on our Wiki here: https://wiki.hornbill.com/index.php/Service_Details