Jump to content

Custom Fields in Details for different Catalog Items


SJEaton

Recommended Posts

Hi

I have a situation where different Catalog Items within the same Service want to use different Custom Fields in Details e.g. one Catalog Item might want to pull through the results of a field called 'Date of Meeting' (which is h_custom_b) so that this can be amended by the request owner if needed partway through the process, however in another Catalog Item, h_custom_b might be for example 'Location' which also needs to be pulled through so it can be edited partway through the process if needed.  Obviously I know I can ensure that field IDs don't clash when configuring the procaps but this will get more and more complicated (and mucky) the more catalog items we publish under this particular service that require custom fields to be pulled through into Details.  

I was therefore wondering if there was anything in the pipeline for being able to customise details fields at Catalog Item level?    

In the meantime does anyone have any suggestions about how I achieve want I'm trying to do?

Thanks

Sam

Link to comment
Share on other sites

@SJEaton

On 13/01/2018 at 11:13 AM, SJEaton said:

one Catalog Item might want to pull through the results of a field called 'Date of Meeting' (which is h_custom_b) so that this can be amended by the request owner if needed partway through the process, however in another Catalog Item, h_custom_b might be for example 'Location' which also needs to be pulled through so it can be edited partway through the process if needed.

 

I don't see why you can't have a different type of information in the same custom field... as long as your BP can have a decision node which branches on catalog item you then know for each branch what type of information you have in the custom field so you can do the BP configuration accordingly...

Link to comment
Share on other sites

Just now, SJEaton said:

Each catalog item has a different BP though

BP or ProCap? ... If you know for sure that for ProCap1 (used on catalog item 1) you get custom_b as "Date of Meeting' and for ProCap2 (used on catalog item 2) you get custom_b as "Location" then based on my suggestion is easy to cater for these two scenarios based on the catalog item...  these two are just examples... if you do this on one or multiple Bps does not matter for this specific purpose...

Link to comment
Share on other sites

  • 2 months later...

Hi @Victor 

I think I'm going to need an example here, There are definitely different ProCaps/BPs for different catalog items that use custom_b for a different field but I'm really not sure how to build the decision node you suggest into the BP?

Sam   

Link to comment
Share on other sites

@SJEaton it won't... let me try and get everything in one place, mainly to make sure I understand correctly.
 

So, you have two PCFs, let's say PCF 1 (which has a form with Custom B as Meeting Date) and PCF 2 (which has a form with Custom B as Location). PCF1 is associated to Catalog Item 1 and PCF 2is associated to Catalog Item 2.

A request is logged (via either PCFs) and the BP starts and reaches the decision node. Here (I think) you need to process Custom B differently depending if it contains a Meeting Date value or a Location value. I mean because of the decision, you (in the BP) know for sure what value Custom B has (it is a Meeting Date or a Location) so you can configure your process accordingly...

Did I get this right?

Link to comment
Share on other sites

Erm,  you just say 'the BP' but each catalogue item has a different BP.  Custom B is used in request details under the Service that both Catalog Item 1 and Catalog Item 2 are published so my query is about how the decision will mean that Custom B in the request details will display either Meeting Date or Location depending on what Catalog Item the request is from.

Sam 

Link to comment
Share on other sites

5 minutes ago, SJEaton said:

how the decision will mean that Custom B in the request details will display either Meeting Date or Location

Ahhh.... right, then, I completely misunderstood the issue/requirement from the beginning... :( .. for some (I don't know what) reason I was under the impression you want to process the custom field within a BP...

I now have (slowly) re-read the original post and I have to say with the current functionality you will have to use different custom fields for "Meeting Date" and "Location" that will be displayed in request details... it gets even "worse" if I may say so, because both custom fields will then be displayed in request details but only one will be relevant for a particular request.... so yes, you would need some sort of custom fields on Catalog Items, rather than Service as you suggested... something for @James Ainsworth to consider...

Link to comment
Share on other sites

So I wasn't the one going mad for a change! haha.  Thanks @Victor

Yes we do have situations where custom fields are displayed even if they aren't relevant for the request but have to live with that (at least for now).

Custom Fields on catalogue items would be amazing!! I may have even asked for this in the past as we do utilise them quite extensively.

Sam

Link to comment
Share on other sites

Just now, SJEaton said:

So I wasn't the one going mad for a change!

I'm quite sure a psychologist will find that we are all mad in some degree... at least I am quite sure I am :D ... (in some degree) ... (more or less) ... (probably more).... :D 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...