cancel
Showing results for 
Search instead for 
Did you mean: 

Creating extensions or page customizing per document type in CLM

Former Member
0 Kudos

Hello,

We are currently implementing a standalone CLM 2.0 install and I'm wondering if it is possible to do the following:

Create extensions and or page customizations per master agreement type. For instance, we have created our own master agreement type and we want to add an extension field that will appear only on this type. So far, I can only figure out how to extend the Standard Master Agreement which aplies to all types.

Any help would be appreicated.

Regards,

Kyle

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Kyle -

CLM (and E-Sourcing) enable page customizations by document type (in your case, Master Agreement Types, but this also works for Project Types, RFx, Types, Auction Types, etc). Extensions, however, are not created by document type. As a result, you will use page customizations to manipulate the user interface after you have created the extensions.

The first thing to know is that page customizations are setup for a business object class. So you will have 1 page customization record for Master Agreements. Once that page customization object is setup, you will add the individual configuration options (overrides as it is called in the user interface) you want to the page customization object.

For overrides that apply to all document types, you will enter the field ID, the property, and value and it will apply to all. For example, to make an extension field required on all master agreements (for all document types), you will use the extension attribute id for the field ID, the required property, and Yes for the value.

Now, to answer your question about making different overrides by document type, you will use the "dimension" capability of page customizations. This capability is seen on the "detail" screen for a page customization override (accessed from the pencil icon next to the override). Logically, the dimension capability works as follows:

if (Dimension Field has the value of Dimension Value) then

apply override

else

ignore override

end

So, to do a page customization override for a specific master agreement type, you would set the Dimension Field to "DOC_TYPE", the Dimension Field Type to "Master Agreement Type", and the Dimension Value to the Master Agreement Type for which you want to apply the override.

The interesting thing about the capability is that the system processes the overrides in the order that they show in the user interface. As a result, you need to have your specific overrides (the ones for a specific document type) before a "general" override which can be the "catch-all" and work for all document types for which there is not an override. For example, if you have 10 document types, and you want a field to show on master agreements created from 1 document type, but be hidden for all others, you could do this with 2 overrides. The first override sets the "hidden" property to No for the specific document type; the second override sets the "hidden" property to Yes, but does not specify a dimension.

The "dimension" capability of page customizations can be complex, yet it is really powerful. Two other points I would add about it: 1) It can be complex to set these up when you have a lot of fields so I recommend using an import file and really thinking it through carefully. 2) The dimension capabilities really only work for fields where the value is set before entering the document; changing a value in the UI while editing the document does not refresh the configuration - it is established once you enter the user interface.

I hope this information is useful.

Regards,

Rob

PS - Please don't forget to add points if this was useful

Former Member
0 Kudos

Thanks Rob, that's what we were looking for.

Cheers,

Kyle

kriti_daga
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Rob,

We are facing one issue, regarding page customizations.

We are doing normal page customization overrides as well as those implemented with dimensions in this case.

There are couple of fields that are visible/required on a particular type of Master Agreement.

The overrides work fine on the document types but fail on the templates meaning the override doesn’t reflect for the MA templates.

Eg : We have a field “Content Type” that should only be required for Master Agreement of a specific type (e.g., UPA Type of MA ), then the dimension fields would be set as follows:

Dimension Field: DOC_TYPE

Dimension Field Type: Master Agreement Type

Dimension Field Value: UPA

This field should be required only on documents and not templates, Hence another property which says Required: False when IS_TEMPLATE IS TRUE.

But this field remains ‘Required’ on the Template also. Not sure what is going wrong here.

Could you please help us with your inputs here?


Thanks,

Kriti

former_member190023
Contributor
0 Kudos

Hello Kriti,

System will process the PageCustomizations in the order they are defined. Thus in your case it will first set 'notRequired' for IS_TEMPLATE; and then will set 'Required' for DOC_TYPE.

Solution is to simply change the order in your screenshot to have DOC_TYPE first and IS_TEMPLATE second.

Regards,

Bogdan

kriti_daga
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Bogdan,

Thanks for the quick response.

The ordering doesn't really seem to solve my problem here. I have already tried that option.

Also I tried creating these by WYSIWYG Page Customization.

I Selected the doc type I wanted, made the field required and Saved. This created the relevant page customizations. The system automatically added the page customization to dimension by IS_TEMPLATE and the order was the same as the one in which I had created those - IS_TEMPLATE first and then the DOC_TYPE.

Any thoughts on this?

Regards,
Kriti

former_member190023
Contributor
0 Kudos

Hello,

I can't imagine why it wouldn't work. We have an identical setup and it has worked throughout all SP upgrades. What version are you on?

PS: Please check that there is no other PageCust that can overwrite our setup. Our working config is:

Answers (0)