Jump to content

Recommended Posts

Posted

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

Posted

@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...

Posted
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...

  • 2 months later...
Posted

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   

Posted

@SJEaton

36 minutes ago, SJEaton said:

What type of nodes follow the decision?

It depends on what you are trying to achieve :) ... What is the BP for? What is supposed to do? 

Posted

lol.  Maybe I'm not asking the right question.  I still don't understand how this will change custom b to either 'Meeting Date' or 'Location'. 

 

Posted

@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?

Posted

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 

Posted
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...

Posted

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

Posted
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 

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...