More custom fields please?

[Alisha]

Hello,

We are using custom fields more and more in our Progressive Captures and Business Processes, and have even used them on the View Details Forms. We are now very limited with the custom fields that we can use and was wondering if more custom fields could be created please?

They are very useful for reporting and storing information in the Business Processes.

Many thanks,
Alisha

[BobbyB]

This really would be beneficial to us.  Custom fields work extremely well for email templates and reporting.  Not requesting unlimited numbers as I realise they add to the size of the databases, but another dozen or so would be great.

Thanks,

[Alisha]

@Bob Dickinson Please could this be considered as we use custom fields so often now?

[Adrian Simpkins]

+1 from me, would love some more VarChar fields to make use of

[Bob Dickinson]

Hi@Alisha

We will discuss internally with the product teams and get back to you shortly

Kind Regards

Bob

[Bob Dickinson]

Hi @Alisha@Adrian Simpkins 

Out of interest, what is the primary reason/need that you and your organisation are using the request custom fields for at the moment?
We are just keen to see if there is other functionality that potentially could be improved instead, to asist with achieving the requirement that might be an alternative to regualrly increasing the number of custom fields available. 

Kind Regards

Bob

[Adrian Simpkins]

Hi Bob,

We use standard mappings across our Services, so for example all Services have the Site as custom_a, the location on Site is custom_b, etc etc. Trying to keep this Standard field mapping across all Services is fine, however some Services do not fit this mapping either because not all standard questions would appear in everything all the time, so some other Services where I want to map I only have the existing shared mapped field value available, and this in turn can create a mixture of data when our teams implement a request list with Custom data fields (hope that makes sense). Or they do not fit the mapping as some requests have a high number of data fields that need to be saved as a custom field for BPMs but do not ask the same Generic questions, which in turn are then used in the BPM logic / Email templates etc

Not a massive issue right now, more of a preemptive strike request from me to see if we could have anymore for future proofing

Thanks !

[Bob Dickinson]

Hi @Adrian Simpkins

Thanks for that, it's very useful. And I understand what you mean about mapping to consistent fields across services - it also makes things easier for reporting across services and replicating working. I'll feed that back to the development team.

Kind Regards

Bob

[Guest Paul Alexander]

+1 for more custom fields for us too please.

[Adam Toms]

+1 for us please. Many Thanks.

[Alisha]

Hi @Bob Dickinson,

We use custom fields for the following:

• Automate emailing capture answers to third party suppliers
• Reporting on specific capture answers
• In the details section of the request e.g. we have a tick box for 'Call out' and other options
• Storing the outcome of a Human Task in the Business Process

Sometimes when we don't have enough custom fields for a capture we have to ask two questions in one field but we would ideally like to have these as separate fields.

Many thanks,
Alisha

[Alisha]

Hi @Bob Dickinson,

We are also restricted with the fields we can use because not all of them are available for use in the Request List view.

I understand Custom Fields P - T are text fields so they cannot be displayed in the Request List view. That leaves us with 15 fields to use, and we're already using a few in the Details screen!

Many thanks,
Alisha

[Alisha]

Hi @Bob Dickinson,

Do you know if there's been any progress with this please? New systems are being introduced all the time and we are needing the custom fields for reporting. 

Many thanks,
Alisha

[Adam Toms]

All,

I thought I'd add this information in, in case people weren't aware.

Whilst this has been going on and something we're waiting for, we have been using the Get PCF answers node to help us reduced the number of custom variables used.

Where we don't need to specifically report on these items, which then limits the numbers of custom variable characters being used, and then for those circumstances where reporting is required, the remaining custom variables can then be used for reporting.

One potential option if it's a struggle to get additional custom fields in, is would it be possible to get SQL reporting out of the PCF answers, which I believe is not possible when using SQL reports. But imagine @Bob Dickinson and the Hornbill developer team would need to understand if this would work as suitable alternative?

I hope this information helps.

Many Thanks

Adam

[Bob Dickinson]

Hi @Alisha sorry for the delayed response on this. 

As far as I'm aware, we have not made any progress in this area, and the custom fields have not been increased so far this year. I will follow up with the developers today and see what their thoughts on the matter are. 

@Adam TomsThanks for the suggestion. We certain can use JOINS in our reporting to query the table that holds the answers to the questions - it depends if that's the primary purpose for using Custom Fields I guess. Other popular uses of custom fields include simply having static areas that can be updated throughout the lifecycle of a request (e.g. if an Implementation Plan for a Change needs to be amended, a Custom Field for store this info and be easily amended from the details section). Also if people want to use particular information in Email Templates then custom fields can be referenced (but PCF answers can't). So often it comes down to the use case - but you are absolutely right to follow the approach you mentioned if it works for you. 

Kind Regards

Bob

[Adam Toms]

Thanks @Bob Dickinson for your reply.

I can certainly say for us pretty much the main time we use additional custom variables (of which has now dropped off using the get PCF answers node) is for reporting purposes only.

Knowing that we can through the use of SQL Joins get the answers out of the Get PCF answers and then to digest this into a SQL report, would pretty much cut down our use of custom fields to very little use indeed.

We've got some upcoming work, where I'm likely to need create SQL reports with catalogue items using PCF answers as opposed to custom fields, I'll look to try this out using the get PCF answers out of it and see if I'm successful in joining the tables I need for reporting.

Many Thanks

Adam

[Sam P]

+1 for additional custom fields (or allowing PCF answers to be used in email templates)

[Smurfy]

+1 here too

[Alisha]

Hi @Bob Dickinson,

Has there been any progress on creating additional custom fields please?

Could we also request new fields for 'Customer Availability' and 'Preferred Contact Number' so we don't have to use our custom fields for these?

Many thanks,
Alisha

[SJEaton]

Yes, more custom fields please!  Are we going to get anymore anytime soon? 

Thanks

Sam 

[HGrigsby]

+++ 1 for more text custom fields please 

We keep running out of them and have used the number fields to capture Yes/No fields to free some up.

Helen 

 

[Sam P]

I am revisiting this post following some help from @Bob Dickinson yesterday where I have been trying to add the answer to more than one IC question to a Hornbill report.  We are 99% sure this is not possible so instead I have had to use Custom Fields.  Whilst this works fine, I find myself fast running out of Custom Fields and hoping I can explain why more would be beneficial to me:

• using the example above where only one IC answer can be added to a report, the fields that were previously populated with answers before changing to custom fields do not / can not all appear in my report and cannot be retrospectively updated without a lot of work.  This results in either missing report data or separate reports for technically the same thing
• with the help of our product specialist, we have "dedicated" a number of custom fields to apply across every single request type and these cannot be used for anything else now.  I can only see this growing as its very powerful and works brilliantly but reduces the availability of Custom Fields for anything else
• Intelligent Capture answers cannot be inserted in to email templates (that I am aware of) so am having to use Custom Fields for this purpose too
• like @HGrigsbysays above I am also having to use 31-40 for Yes/No answers
• as @Adrian Simpkinsdescribes, re-using Custom Fields often means that data can appear somewhere else where you are least expecting it
• we use Human Tasks a lot and Custom Fields are updated in the BP to be used again later in the Request, like @Alisha
• also, sometimes its just REALLY HARD to remember what you have used and where, even with copious notes (is there a report for that @Bob Dickinson?)

Over but not out  

[Sam P]

As Victor has confirmed in another post that its not possible to report on Stages and Checkpoints unless they are mapped to Custom Fields, this serves as another reason why I feel we could benefit from some additional Custom Fields.  I don't think for a minute this is an easy thing for Hornbill to implement however some indication of whether or not it could even be considered would help   

[samwoo]

I just wanted to +1 this as improvements can be made in this area, but I guess it's the how that's going to be difficult. 

I also struggle with remembering what field is being used for what across all services... I have tried hard to remember to add notes to my ICF and BPM that details each custom field and what is populating that field, but the problem is remembering to update when making changes or forgetting to do it full stop. It also clutters the stage as well making it harder to navigate and gets confusing when extracting data as well. 

What would've been good would've been to have user definable customer fields per service, but that does come with its own set of issues (ie. How the information is displayed in columns on reports) or allow a central location to manage all custom fields and enable assigning the custom fields to be used against one or more services, but again there would be lots of technical challenges to overcome, but doesn't sound impossible to achieve. 

[Malcolm]

Big +1