SJEaton Posted January 13, 2018 Posted January 13, 2018 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
Victor Posted January 15, 2018 Posted January 15, 2018 @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...
SJEaton Posted January 15, 2018 Author Posted January 15, 2018 Hmmmm, I think I get what you are saying. Each catalog item has a different BP though? Sam
Victor Posted January 15, 2018 Posted January 15, 2018 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...
SJEaton Posted January 15, 2018 Author Posted January 15, 2018 Ok. I'll have to have a play as not 100% sure I understand how it will work Sam
SJEaton Posted April 12, 2018 Author Posted April 12, 2018 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
SJEaton Posted April 12, 2018 Author Posted April 12, 2018 Hi @Victor Ok but I don't know what I'm branching to?? What type of nodes follow the decision? (sorry if I'm missing the point here) Sam
Victor Posted April 12, 2018 Posted April 12, 2018 @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?
SJEaton Posted April 12, 2018 Author Posted April 12, 2018 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'.
Victor Posted April 12, 2018 Posted April 12, 2018 @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?
SJEaton Posted April 12, 2018 Author Posted April 12, 2018 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
Victor Posted April 12, 2018 Posted April 12, 2018 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...
SJEaton Posted April 12, 2018 Author Posted April 12, 2018 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
Victor Posted April 12, 2018 Posted April 12, 2018 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 ... (in some degree) ... (more or less) ... (probably more)....
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now