Extra Details Issue

[SJEaton]

Hi

I'm having an on-going issue with setting up extra details.  I've set up 2 in my I Want to Recruit service - 'Start Date' and 'Employee Number' as you will see from the first screenshot.  I have used Custom_A and Custom_B fields.  They seem to work ok and then suddenly 'Start Date' disappears from Details in the request - see second screen shot.  I've tried adding them in via the service and via the details 'design' option but still get the same issue.  Why is this happening?

Sam

[Victor]

@SJEaton I don't think it works using the service "Extra Details" ... to be honest I am not sure how "Extra Details" is supposed to work  ...perhaps all fields added there should be available to all request types...

Quick fix, on the request itself (rather than service), edit the "Details" section and add the "Start Date" field there...

[SJEaton]

OK, I did do this but it disappeared again.  I wasn't sure why this happened and I don't want it to happen when we go live ;(

[Guest Chaz]

@SJEaton these fields are not used anywhere else in the product, but we left them there in case there was specific information that could be set against the Service. If you want this information to be shown against a Request, you'd need to go to the 'Request Config' tab and then click on the 'View Details Form' to configure it for the request types that require this information.

[Victor]

@SJEaton so, as @Chaz mentioned, the "Extra Details" section is deprecated/obsolete. You need to use the details of teh request itself to add/remove custom fields. Also, it is quite easy to miss the "Apply Changes" button which is what actually saves the changes on the details section:

[SJEaton]

Aha!  Yes, hopefully that will do the trick, thanks

[SJEaton]

Don't ever get rid of them as they are useful for us!

Sam

[Victor]

@SJEaton we're not getting rid of the custom fields on request, we might (emphasise on might) get rid of the "Extra Details" section on the service itself as we don't use it anywhere else. Custom fields and customising the details section of a request will be there and can be managed via the request itself...

[SJEaton]

Hi @Victor, the email I just sent you kind of relates to this same issue.  I set up the 'Start Date' and 'Employee Number' extra details in the details section of the 'I Want to Appoint' request itself using h_custom_a and h_custom_b and it worked fine.  The trouble is that I have now created a new BPM called 'TEST Honorarium Process - auto authorisation' which requires a different extra details field so I set this up in the details section of the request itself as h_custom_a.  The trouble is, even though the honoriarum process is under a different service, it has over-written the 'Start Date' extra details field in 'I Want to Appoint' requests.

Does this mean that whatever extra details you set up will show on every single request no matter what BPM the request triggers or service if falls under?  This would be horrible if its true.  I did try this out with another service/bpm though and I cant see the extra details so it is really baffling me!!

We really do like the idea of using extra details so want to get this working effectively if we can therefore any further advice would be appreciated.  Thanks

Sam

  

[SJEaton]

Here is a doc with some screenshots showing what's happening.

screenshots.doc

[SJEaton]

Can anyone else take a look at this whilst Victor is on holiday?  We are planning to go live on the 14th September so I'd like it sorted before then if possible, cheers.

[SJEaton]

@James AinsworthI don't suppose you can assist with this can you? 

[James Ainsworth]

Hi @SJEaton

I'll get myself up to speed on this post and see what I can do.

Regards,

James

 

[James Ainsworth]

Hi @SJEaton

Sorry if I'm covering ground that you have already crossed.  I thought I'd start with going over the areas to do with custom fields and we can then narrow down to where the issues are.

Service's Extra Details
On a Service form there is the Extra Details section which sits under the service's Details tab.  This allows for custom fields to be applied across all Services just for this particular area on the form.  If you open a Service and you add a custom field to the Extra Details, it will be available for all Services within this section.

One thing that we have done to minimize the information on a form is that when a custom field is added to a form it is hidden unless there is content added to that field.  On each field when in the form designer there is a cog icon where you can select an option to always show the field, even when the contents is empty. (This applies to both the Service Extra Details and the Request Custom Fields)

There was a mention in this post that this Extra Details section might be deprecated.  This is not the case.  We will over time add to the Extra Details section providing some default fields that are common to services.  These custom fields in the Extra Details section have no relation to fields that are stored on a request.

Request Details Custom Fields

There are two options for the Request Details Custom Fields.  One is the default configuration and the other is a per Service configuration.  There are also two places where you can modify the custom fields, one place is on the request itself or you can do it from the Service form under the Request Config tab where each request type has a View Details Form button .  I would recommend using this for customizing requests per service.

In order to change the default configuration you need to have a request that is not associated to a Service.  This would normally be done very early on in your configuration where you specify fields that you see being required or provided as a starting point for all requests in all services.  More commonly this would be done at the service level.  Each Request Type on a Service starts off by using the default configuration.  As soon as you edit the custom fields for a particular request type on a service, the default form is no longer used and all requests of that same type that are raised for that service will use the fields that have been defined on that form.  There is an option to restore the fields back to the default.

If you are using the request form that is associated to a service to customize the fields, this will apply to the configuration for that service in the same way as editing it from the Service form.

 

In your Word document that you provided above, you mention the use of the h_custom_a as an extra field. You are looking re-use this field on different requests, based on the services they are logged against.  Using the descriptions above and using the h_custom_a field I added this field to the default configuration request form and on two separate services.  In all three cases I was able to provide a unique label for the same field (h_custom_a).  If this is not the same as you are experiencing then we need to see what is different with your configuration where the label for the custom fields is not being maintained or is being overwritten.

I hope this helps and leads us to understand how to get this working for you.

Regards,

James

 

 

[SJEaton]

Thanks James. 

OK having read the above a few times, I think what I need to do is set up the Request Details I want via the Service form then under the Request Config tab and Service Request tab and the View Details Form.  I haven't tried setting them up under here before so this may be the solution.  I just need some further clarification:-

I understand that the Request Details I set up here will apply to all of the Catalogue Items within the Service/Service Requests Tab.  This should be fine but as I add each custom field it uses h-custom_a, h_custom_b, and so on in order.  Can you please confirm if this means I cannot use custom fields I have used in the View Details Form in any of the progressive captures that are configured for the catalogue items within this service? e.g. If I have set up Request Details against h-custom_a and h_custom_b in the View Details Form, when I configure the ProCaps I need to start at h_custom_c for any custom fields I need?

Sam

[SJEaton]

I think I've answered my own question here as I've done a test and set up 3 request details in the View Details Form using  h-custom_a, h_custom_b and h_custom_c.  A and B are for my I Want to Appoint process and C is for my Honorarium Payment process.  The screenshots below prove that on the I Want to Appoint request C is populated with information entered in h_custom_c on the I Want to Appoint ProCap, and on the Honorarium Payment request A and B are populated with information entered in h_custom_a and h_custom_b of the Honorarium ProCap.  

I will therefore have to ensure I don't used h-custom_a, h_custom_b and h_custom_c in any of the ProCaps under this service.  This may cause a slight issue for us as we have already used all the custom fields up to Q in some of our ProCaps so we will be 3 short

Sam

 

[SJEaton]

Also, if we ever identify a further field we want to set up in Request Details of this service it will use h_custom_d and then any h_custom_d fields used in all other ProCaps will have to be changed along with email templates that pull in these as variables.  A lot of work and faffing!  Is there therefore any way around this?  

Sam 

[Guest]

Hi @SJEaton

Sorry I'm a bit late to the discussion but I just wanted to contribute, and potentially take a step back. 

Firstly - I would advise to ALSO configure any custom fields from Service and not directly from a request. Doing it from a request simply makes thing more confusing, and you have more control when using the "View Details" for on the Service. 

If we were to create a brand new Service, as mentioned above, we have the option to use up to 17 custom fields (Custom A to Custom Q). This is also per Request Type - so you can have 17 custom fields for Incidents against your Service, and 17 for Service Requests against your Service. 

In my screenshot below, I've configured them all in the view details form:

 

I've also made all of this visible even if no value exists. And as you can see, when I raise  an Incident, this is what I see:

 

You can have multiple Catalog Items with Progressive Captures against a Service - and as you have done, you can map the responses to the catalog items. But regardless of how many you Catalog Items/Progressive Captures you have, you still only have the 17 Custom Fields against that Service to play with.

 

So for Example - in my Service "Bobs Service 10" I have two catalog items:


For my "New Starter" Catalog Item, I have created a Progressive Capture and have 16 questions, all about the new starter e.g.

"What is the Starter Name?"
"What is the Starter Date?"
"What is the Starter Manager?"
.
.
"What is the Starter Email?"

In theory I can use 16 of my custom fields against that Service, each with a unique label, to map all the answers to - if I need to. So:

"Starter Name" --> (Maps to h_custom_a    "Starter Name")
"Starter Date" --> (Maps to h_custom_b    "Starter Date")
"Starter Manager" --> (Maps to h_custom_c    "Starter Manager")
.
.
"Starter Email" --> (Maps to h_custom_p    "Starter Email")
Now I come to my Leaver Catalog Item and Progressive Capture. Because this falls under the SAME service, if I want to map to any custom fields with a unique label, I only have 1 left - h_custom_q. 


If I have understood correctly, you are in a scenario where you have multiple customer questions in a number of Progressive Captures and you are trying to capture them on the request details. The bad news is, that as per above you are limited to the 17 per service. 
So how do you resolve this? You have a few options:

1) Split out the Service - In my example above, if I really need to capture those questions in the request details,  I would create a new service that is specific to a New Starter. Each Service gives you 17 Custom Fields per type. 

2) Consider why you need the Answers as Custom Attributes - All Progressive Capture answers are captured within the questions section anyway. The main reason that people want to map answers to Custom Fields is so that they can be edited in the future (e.g. a Change Implementation Plan). But if the data is unlikely to change, (e.g. the Name of a New Starter) do you really require that answer to be mapped?

3) User Shared Labels - A bit more tricky and will involve some careful consideration - but are there any custom attributes that can be shared across you Catalog Items? In my example above, perhaps instead of "Starter Name" and "Leave Name" as the label for h_custom_a, I would just have "Name" so it can be shared. 

Apologies if this is going over old ground or I have misunderstood any of the original issue that you posted - I also appreciate this is a bit harder to do when you have already set up your Service Catalog in a particular way as you need to rework it rather than begin at the Service/Custom Fields level as I have done above. But please let me know if you have a specific issue or problem to overcome and perhaps we can assist a more granular capacity. 

Kind Regards

Bob

[SJEaton]

Hi Bob

This isn't quite what my issue.  I don't need to capture progressive capture answers in request details, I want to capture additional information in request details partway through a workflow but when I set up the fields they get overwritten when I set up further fields under another service.  I understand James has updated you now.

Sam

[Victor]

@SJEaton and anyone following this: The issue with field labels not being unique per service is actually a display issue in Internet Explorer. The configuration and underlying data are correct, so the functionality is correct (i.e. a custom field having unique field labels in different services). We are now working to identify the display issue occurring in IE and having it fixed.