Steven Boardman

@lee mcdermott the Variable Visibility section on this wiki page should give you what you need - https://wiki.hornbill.com/index.php?title=Email_Templates

@LouiseT this should be possible: Site - In your progressive capture, if you are using the default site form, then the site will be added to the request automatically and this variable is available to use in the email template variable picker. If you are using a custom form in progressive capture and a custom question, if you name that custom field h_Site this will map the answer to the site field on the request and again will be available to use in the email template variable picker https://wiki.hornbill.com/index.php?title=Mapping_Fields_from_Customised_Forms The same applies for assets, if you are using the default asset form, then the selected assets will automatically added to the request. In order to use these in the email template, you can use the business process engine to put the asset values into a custom field, which will be available in the variable picker in the email templates. Use the Get Assets option Follow this with an Update Request > Custom Fields and use the variable picker to inject the output param - assets into your chosen custom field. If you are not using the default asset form in progressive capture, but instead a custom form and a custom field which is using the asset picker, again you can simply set the field id to be a custom field like the sites example above (eg h_custom_a) Finally ensure you use a get request details node in your business process before using a node to send an email using an email template, this will ensure that you have loaded all the latest values from the request (site, assets) and that there updated values are available to be injected into the email template Hope that helps

@Smurfy the following wiki page should hopeful help - https://wiki.hornbill.com/index.php?title=Service_Manager_Notification_Settings Essentially the notification settings are global by default, but if you wish to enable them per agent then there is a system setting to enable, and once enabled each agent will see the Service Manager notification options on their profile and be able to set their preference. guest.app.requests.notification.allowUserDefinedNotificationType Please take note of the considerations detailed in the wiki page before enabling the above setting

Sorry @Alisha I am not aware of any movement on this one just yet.

Hi @Jack_Podmore sorry your having issues here. I've attached a simple business process example which will: 1. Get Customer Info 2. Write the Customer Site to the Timeline 3. Branch off the Customer Site value - so if London it will go one way, and if not London it will go the other Hope this helps to trouble shoot your process Steve customer-site-example.draft.bpm.txt

@Berto2002 a new Clear authorisation decision option will be added to the business process designer. This will allow you to remove an existing authorisation state (approved / rejected). This new option will be available in the next service manager update which is scheduled to be pushed in the coming weeks.

@Berto2002 I have flagged this enhancement request to the AND/OR condition with the team who manage the custom buttons.

@Adrian Simpkins A couple of things to check 1. Is the request a Service Request or Incident? the Cancel option only applies to Service Requests 2. Does the user have the Self Service Request cancel user role? I can certainly see the cancel option under those conditions for a basic user

@Berto2002 you could take a look at the Get Timestamp option which is available in the iBridge > utilities in the business process designer This will allow you to set the scheduled end date as the Starting Timestamp, you can use the Add Operator, and then increment the value using the Minute option by one, and then use the output timestamp as the expiry. You would of course need to use this option ahead of the window expiry action in your workflow. Something to look at i hope

@Berto2002 I'll see if the wiki can be updated to cover these nuances. The only other one which springs to mind, is that for Request Type, the value needs to be lower case so incident rather than Incident for example **Update** The following wiki page has been updated to include a Condition Values section, this will be used to add any specific formatting needed for the values of the conditions for each app and each app entity. https://wiki.hornbill.com/index.php?title=Custom_Buttons

@Berto2002 try the format status.open or status.new etc (case sensitive)

@RIchard Horton there is also a way of getting the catalog ID's and Services through the employee portal UI. If you navigate to a specific service, you will see the catalog options (assuming they are visible on the portal) If you click on each one, it will open the relevant progressive capture form and in the URL bar you will see both the service ID and Catalog ID as below: https://live.hornbill.com/rhdemo/catalog/new-service-request/com.hornbill.servicemanager/5/325/ Where 5 is the Service ID and 325 is the Catalog ID

@Martyn Houghton I have flagged this to the team again for you

@Berto2002 there are a few things to address here: 1. You can still have the connection being added to the request during progressive capture, so the agent's can still see who the approver is for the request, it will just be in the business process, you are looking up the line manager via the customer's manager logic as detailed above, but if you need for the agent's to know who the approver is, you can continue to still use the connections. Alternatively you can utilise other options to make it visible to the agent who the line manager is on the request * Add a request notice and inject the customer's manager's name into the notice * Post an update into the timeline of the request, including the customer's manager's name (albeit this will disappear down the timeline overtime). * You can include the customer's manager name in the customer section of the request view So it shows as follows: Obviously some options are more visible than other's, but hopefully some to consider. 2. Request Connections - There are two sides to this, firstly the adding of request connections via progressive capture - this is correct, you can only add one connection at a time as a requestor (this is actually via the user data query). However from the agents view of the request, they can add multiple users as request connections of each and any connection types you have defined, as below: As such, in the case of the external authorisation, where it's input paramater is either a declared email address, or a single variable value, attempting to look up the connection's of a request for this purpose it problematic. Finally, if it is a requirement to use the 'user' selected in a progressive capture answer (using the user picker) as an external authoriser, then you can of course use the business process to add them as a connection to the request (for agent visibility purposes), you can simple inject the 'raw' value answer to the progressive capture user selection question, into a 'get user' node, and then their email address will be returned as an output parameter from that node, which can be injected into the external authorisation node.

@Berto2002 have i read this correctly, that the Connection is the customer's manager? If this is the case, and you want them to be the approver in the external authorisation option, then if you use a Get Request Information > Customer Details node One of the outputs is Customer ID You can use this variable in the following option: The bottom option here, will be the Email address of the customer's manager Then using the External Authoriser option you can inject that variable. To address your second point, before the External Authoriser node, you could add a Decision, and have two outcomes, each with a custom expression, in one of the custom expressions, you could do a contains on the email variable value from the Get User Managers Details options - and if it say had @YOURDOMAIN then branch to the External Authoriser and the other outcome could be a No Match from which you could decide what to do if no manager email address was present - You could of course choose a different custom expression like Is Set or something like that, if you prefer. Finally, there is no option to get connections details which would help here, as it is possible to have multiple connections on a single request (of the same or different connection types), and when it comes to the external authorisers, this will only accept a single approvers email address, so we would not know which of the connections of say the same type to return, in order to get their email address. Hopefully the above if useful and the approach can work for you

@AndyHill @Berto2002 for the email template, there is a modifying function for converting the date/time variable to the correct local time, this is mentioned here on the wiki: https://wiki.hornbill.com/index.php?title=Email_Templates So in the case of the start and end dates for the scheduled change, the email variable in email template would be as follows: {{.H_start_time|formatLocalTime}} {{.H_end_time|formatLocalTime}} This will then use the system regional settings as set under the following settings: system.RegionalSettings.timezone system.RegionalSettings.dateTimeFormat In the absence of the modifier on date/time values in the email, it will use the UTC value in the database The above settings can be found here in the admin console: Once the modifier is specified in the email template the output should be as follows: I hope that helps on the email template formatting front. As the display on the request notice has already been logged via the support channel i'll leave this with the support team to manage with you @Berto2002

@Sam P looking at this i would think that all the task nodes are using the same / original Get Request Information node to decide who the owner of the ticket is? If you add a Get Request Information node in front of each task, and use these for their related task, it will look up who the owner is at that point in time, rather than relying on an OLD get request information node, which would return who the owner was at the point in the business process when it was called. So just add a Get Request Information node in front of each task node, and use the variable picker to insert the owner from that node rather than a Get Request Information node from earlier in the process Hope that helps

@Mark (ESC) there isn't a setting to control this as per the activities on a single request, however there are some techniques which could work for you depending on the sequence of events the various teams need to perform. For example - On the primary request you could use the Lock business process action, for the Resolve action - thus not making it possible to manually resolve the request, until such a time as the Resolve action is Unlocked by the business process. If the teams work in a sequential order, the primary request can Auto Log the first Linked Request, then be put into a Suspend - Await Update state again using the business process options, and this can include a specific textual update it is waiting for. The first linked request, in it's business process can complete it's actions, and then automate the Update Linked Requests business process options to pass a specific textual update to the primary request (which it is waiting for), the primary request can then auto spawn the next linked request, and be put back into a Suspend - Await Update for the next linked ticket and so on, until all sequential team actions are performed, and then the primary request's business process can either Unlock the Resolve action, or auto-resolve from the business process itself. This works fine for sequentially ordered processes, but becomes complicated where parallel of actions is needed - and for this the approach Nasim mentions above with activities (Tasks) maybe the way to go. Anyway perhaps this is useful in your scenario.

@Tina three things to check 1. Have you enabled this setting? This will allow the SL to be auto re-evaluated when a ticket like priority is changed 2. Do you have rules enabled on your Service Level, which will be automatically re-evaluated when a ticket param like priority is changed? 3. Do any of the rules in step 2 relate to priorities ? i.e have you set a rule which changes the SL if the priority is x or y Finally the rules will be evaluated from top to bottom, and once a rule is met it will inherit that SL, so just double check there is nothing in your rules that might evaluate to true, before it hits a priority based rule in the list.

@Alisha using the approach above the customer (of the Incident linked to the problem) would receive an email - the email would let them know there is an update and a link to it - exactly the same way as the Incident update one works. Customers can't view Problems, Known Error or Release tickets on self service to see any updates, so email is the mechanism and they will be able to see the update on their Incident ticket, from the link in their email - it just so happens in this scenario, that the original update was made to the problem, and it cascaded down as an update to their Incident, and in turn they get an an email about the update This works as below for the two scenarios: Problem Updated - > Linked Incident Automatically gets Updated > Customer gets automated email letting them know there is an update Incident Updated > Customer gets automated email letting them know there is an update I hope that clarifies the email the customer gets from a problem or an Incident

@Alisha there isn't an option for Problem, Known Errors or Release ticket types. The logic here is that these are typically not customer facing ticket types. However if you have Incidents linked to a problem record, and you make an update to the problem record, and use the Update this and linked requests if the update to the Problem is marked as Customer visibility, it will update the linked Incidents and the customers of the Incidents will get the update as it's been applied to their Incident and is Customer facing I hope this makes sense?

@Alisha if tickets are linked, the option to update the linked tickets will show, if there are none linked it won't Settings to enable are in the admin console > Apps > Service Manager > Settings Hope that helps

@Berto2002 if you change the entity to Change Requests and create an email template against this entity You will have the Start and End date variables available to you (the list of variables will include all the change attributes plus the standard request variables). When your using a different entity email template, be sure in your business process node for sending the email, to ensure you have set the Email Template Entity field accordingly

@Cassie this is strange - I can only replicate this if the tickets in the list are not assigned to a team or owner, if they are the options should appear. In order to get this looked into further (and to ensure i am not missing something obvious), i would suggest getting this logged with support, so they can assist directly - https://www.hornbill.com/support

@Cassie do the tickets you have selected have a team assigned too them? if you use the assign option do the other options then show for you?