James Ainsworth

Hi Greg, Reading your post again, are you looking for a condition statement in your BPM to give you an option in the front-end whether you send the email or not? If this is the case I don't believe there is an option for this. If emails on closure are not mandatory you could consider using the email snippets. You can create a snippet called ''Closure Email'' that you share with your team. This can then be sent when it is appropriate. As this is being done from the client, you can then also use the CC/BCC options. Regards, James

Hi Greg, Thanks for your post. The sending of an automated email on the closure of a request will most likely be something that has been set up in your workflow. This is not something that we do by default. Check the BPM workflow that is being used for your requests and look for an automated task that has been added to send these emails. On the email action within a request there is an option for adding CC and BCC recipients. This is on the top right next to the attachment option. I hope this helps. Regards, James

Hi Martyn, I just wanted to follow up on your query about searching for users in Administration. Under System->Organisational Data->Users, the list of users now has a quick search field where you can type in the User ID, firstname, lastname, or full name to locate a user. Regards, James

Hi Martyn, I wasn't sure if you managed to get this working, however for others reading this post I thought I'd include a link to our LDAP User Import Tool Documentation.

Hi Gareth, Item 4 - Connections in Progressive Capture. This is a change that we already have in our backlog but it has not been schedule for development as of yet.

Gareth, Item 2 on your original post may be able to be accomplished as part of your workflow. At the end of your workflow you can send an email out once the status has changed to closed or you can create a 'Closure' stage that manages this and other things that need to be done once closed.

Hi Martyn, Thanks for your post. I will have look at the existing behavior to determine what is currently possible. Providing a shared mailbox per service seems like a suitable way to go.

Hi Martyn, Thanks for your post. I wasn't aware of this being an issue. I'll ask the development team to investigate and one of us will feedback once we have an understanding what is happening.

Hi Paul, Could you try one thing for me. Can you remove the & from the name of the service and see if that makes a difference? James

Hi Tina, The initial thoughts with the on-hold was that we would start with having the actions disabled as it could be seen that if work was being done on the request that it shouldn't be on-hold. However, it is always important to recognize that different people work in different ways, so as Martyn suggested we do have a change in our backlog to give you control over which actions are available when a request is on hold. This change has not been scheduled as of yet, but we will continue to review and prioritize based on the feedback provided. Regards, James

Hi Tina, From the request list you are able to type in the customer name into the Filter and it will narrow the list down to that customer. We do also have changes in our backlog to provide lists against the user profile and a contact record. These have not been scheduled as of yet but something that you will see added in the future. James

Hi Paul, On the creation of a service everything other than the Portfolio Status defaults to a setting which will make the service available on the portals for customer and to support staff within Progressive Capture. The Support Teams and Subscribers by default are set for the service to be supported by all teams and subscribed to all users. Adding to either of these will then only allow the service to be visible to those either supporting the service or those customers that have been subscribed. The screen shots you have provided above all seem correct. The only other areas to look at are the Supporting Teams and Subscriptions. Do you have a screen shot of how this is configured? Also, could you confirm if you have other services that are working and if it is just this one service that is not displaying. Regards, James

Thanks for your posts. Just to let you know that we do have a change in our backlog for this which I will bring forward to our next review and let you know once we have an update. Seeing multiple posts on the same topic is great for everyone as we can see what is the most important for our customers. Keep the posts and ideas coming!

Hi Martyn, We are looking at introducing an application setting that will allow this to be configurable. To begin with this will be a simple on/off for this feature that would apply to the portal as a whole. At a later date we can look to have more granular setting within the services. Provided that there are no technical concerns, this is something that we should be able to progress. Regards, James

Something that we can look at is having what we call the Title of the post exposed in the timeline of a request. If you look at any of the posts in your Newsfeed, each post has a title that will say something like "James posted on workspace...". In fact, if you are following a request, you will see the updates for that request in the Newsfeed with this same title. The reason it is not on the timeline at the moment is that it also replicates information such as "James posted.... request IN0934933'' which we already know the request ID as we are viewing the request so it was seen as extra information that wasn't needed. I will have a look to see what options we have.

Hi Nasim, Thanks for your post on the topic of Bulk resolve calls. The original discussion can be found here. I just wanted to let you know that I haven't lost sight of this first discussion and I'm still considering options to implement additional actions when you select multiple requests. We have so many great ideas and requests for features in the forums and we will continue to provide solutions into the products. You are right to post again to bring it to our attention, and I just wanted to assure you that your original post was still being looked at.

Hi Gareth, I can see that controlling who can change the scheduled dates is a valid and useful requirement. We are looking at options for hiding some of the different Action Items such as the Schedule Action as part of your process. So once it reaches a certain stage you would be able to hide the option to schedule. However, this may not help where there is a valid requirement to change the schedule. Would having this option help? James

Hi Martyn, Our direction with managing customers against changes is using the Connections feature. We have some upcoming changes which should help assigning customers to a change in progressive capture as a connection. My concern with putting in a temporary fix is that we will end up with two different places or ways of associating a change with a customer. Regards, James

Hi Martyn, I can see that there would be some benefit in providing different help text to a support person than an end user when using custom forms in a Request Catalog Item progressive capture flow that is used by both the support person and the user. Maybe providing slightly more '"technical" help. The concept behind the Request Catalog Items is that the support staff can raise something on behalf of a user if the user was to phone in rather than raise something on self service, following the exact steps that a user would experience. Possibly even prompting the questions to the user over the phone. The end result being exactly the same, independent of whether if it was raised via the portals or on behalf of a user by a support person. With this in mind, I would be interested to get some examples of the differences in help text that you would want to provide.

Hi Gareth, In this scenario do you think it would me more fitting to provide some way of recording suppliers and/or supplier services? At the moment our Services have a focus on business services and eventually will allow for technical services to underpin these. These technical services could include those provided by 3rd Party Suppliers. We have designed the assets to be internal and these can contain a great amount of detail to record costs, depreciation, location, along with import and integration options. Much of this may not be needed or applicable when working with 3rd Party Suppliers. Do you have any 3rd Party Supplier services such as printing where they may supply hardware that is located on your site or is it all hosted? I would also be interested to know the minimum information that you need to record such as Name and contact information of Supplier Status of Service/Hardware Many thanks, James

Hi Steve, Thanks for your post. The Mobile Service Manager app currently provides the management of existing requests that have been assigned to a support person or any of the teams or services that they support. This includes activity management for these requests. We have plans to extend out the abilities for raising a request as well. This work has not been scheduled as of yet but we will keep you posted on any update to this. Regards, James

Hi Gareth, I would be interested to know the types of assets that you are supporting for your external contacts and the level of information that you would like to store against them? There are some considerations for providing something to manage "products" rather than "assets" for external contacts. Martyn is correct that the assets have an internal focus and you can assign only internal users. Regards, James

I'm going to try not to get too entangled in ITIL and best practice other than to say that many areas in Service Manager started with ITIL in mind and from there built on to provide the flexibility needed by our customers. By the sound of it, what needs solving is that ability to report on a customer and show which requests, of any type, that are linked to them. What we are trying to solve with having the "Raised by" instead of the customer is that it give an internal reference point for either the CAB or the engineer facilitating the change to go back to. As a result of an incident being raised a change may be requested to fix something. This request will generally come from the incident owner, problem management, or possibly someone who has been brought into review the incident because of a particular area of expertise. These will generally be the people referenced against the "Raised by". The Connections feature was added as a way to manage the connection to the customers. Some may only have one customer linked, but others will find that a change may impact or provide something for multiple customers. The Connections allows for both scenarios where as the "Raised by" is only ever a single person. Some of the progressive capture forms are specific to certain types of requests. It is not always obvious where each form can be used. The Customer Search progressive capture form is primarily for Incidents and Service Requests. We have a planned change for a new progressive capture form to add Connections when raising a Change or a Problem, however we may find that the Customer search could be made to accommodate this when used with Changes and Problems. James

We had not originally considered this as from previous feedback Service Desks did not want customers bypassing the defined entry point to the service desk by contacting a support person directly. It can also become problematic when that Support person is on holiday or off on sick leave and the customer is trying to phone that individual. The other consideration would be that in multi-team environments some teams may want to publish their phone numbers and others may not. So the decision to publish phone numbers would have to considered across all teams if it was a single on/off setting. I would be interested to hear from other customers about their thoughts on publicizing more information about the individual support staff in the portals. There may be an immediate difference of opinion depending on if one is supporting internal users within their organization or external customers. Possibly hiding individual contact details is an old way of thinking and we need to allow these channels to be opened up. James

Hi Martyn, Other customers have also suggested that this would be desirable. One of our challenges is the name of the column. As different services or teams may use the custom fields for different information we need to consider how the column headers are displayed in a way that is descriptive enough to understand what the contents is and not just have custom_a at the top. I would also be interested to know if you have any fields that you think could be added as a standard field to the requests. We may find that fields that are possibly more generic to the way that others work can be approached in a different way from the custom fields.