Global Rules for Standard Check In and Search Only

Or another way to put it...Global Rules that don't take effect in Profiles.

I was recently setting up a UCM instance and was configuring my Profiles to show just the metadata I wanted. And more specifically, I was trying to change the Standard Check In and Standard Search pages to be as clean as possible. To do that, I used Rules in Configuration Manager set to 'Global' and used the 'Is group' selection with the group hidden by default. Here is a sample of what it looks like:


As you can see it makes the default check in screen much cleaner and easier to deal with for most folks. But still allows for access to all of the other fields by dynamically opening the field groups

But I hit a major snag when I tried creating specific profiles and tried to reuse fields from within the global groups. For instance, let's say I want to create an 'Images' profile that had the Standard Fields group from above, but added a new group called 'Image Fields'. And that group had fields that are currently defined in other groups such as the Web Content Management and Other Fields. Well, because those groups were defined as global, I'm not able to overwrite them with a rule in my profile. The global ones win out. So at this point, I can show/hide certain fields with rules in my profile, but I can't control the grouping.

And that's when the workaround struck me. You can use an activation condition on your global rules that force them to execute only on the standard Check In, Search, and Info pages. So basically, you're turning the standard pages into it's own profile. So the activation condition that you add to your global rule would look like:

not (#active.xProfileTrigger)

In this case, xProfileTrigger is the field I use as my profile trigger. BEST PRACTICE TIP: Although it's easy to fall into the trap of using Type (dDocType) as your profile trigger field, for the most flexibility it's recommended to use a custom metadata field for that trigger.

The above example will exclude that that rule for every profile. But maybe you only want to exclude it for certain ones. Then you can simply construct your activation condition to not activate for those certain ones.

not (strEquals(#active.xProfileTrigger,"Images"))

[Updated 9/16/09 - Added a space between the "not" and "(" in the activation condition code]


On the Best Practice Tip: What are the disadvantages of using Type as the profile trigger field?

Posted by Donna on October 05, 2009 at 06:26 AM CDT #

Type is a system field in UCM/URM that is different then other metadata fields.
1. It is always a required field. Every item in the repository must have a 'Type'. Because of this, I typically recommend that Type be a very global and generic value. Things like 'Document', 'Email', 'Image', 'Code', 'System'. And then use other fields to better describe that content. If you try and be specific, the Type field can quickly become large and unwieldy.
2. It is used as part of the Weblayout path. So if you change an item's Type, you change the Web Location URL path. So making changes to it has a greater impact then other fields.
As an example on a recent proof-of-concept that I worked on, we decided to take a shortcut and simply use the Type field as our profile trigger. We created the Types we needed and proceeded to go through use cases. But almost immediately we came to a situation in which they had content that was the same "type" (in this case, Image), but they needed to have two different profiles for different scenarios. Because we used Type, we now needed to create another Type value and split them up...but this was confusing because to the users, both groups of content were "Images". Had we used a custom metadata field like ProfileTrigger, we could have seamlessly added our new value and broken them apart. And Type could have stayed 'Image' for both.

Posted by kyle.hatlestad on October 05, 2009 at 11:42 PM CDT #

Thanks again, Kyle. Good information and given in such a way that it is easily understood.

Posted by Donna on October 06, 2009 at 04:54 AM CDT #

Could you give some reccomendations or links to the literature on how it is better to classify the documents/content. In the help files it is said, is should be based on functionality and there should be no more than 50 types. Is it better to use the same types for the entire company or to define them within the departments? And then the same question to the profiles. Should a profile be defined for a department or for a document type? And have you ever used folies? Thank you.

Posted by Gulnara on March 16, 2010 at 04:10 AM CDT #

Is there a way to hide the standard check in link under the new check-in drop-down menu?

Posted by Seth on November 04, 2010 at 08:45 AM CDT #

Hi Kyle,

Do you know why doc_info page can not hide rule? I checked Hide group by default option on Edit group header dialog, but rule is showed only on doc_info page. On checkIn and other pages that role is hidden by default. Thank you in advance.

Posted by Helen on December 04, 2011 at 08:39 AM CST #

Hey Helen,

This has been a bug (#12914820) that should be resolved in the latest CS10gR35UpdateBundle for 10g and Patch Set 5 (PS5) version when that becomes available for 11g.


Posted by Kyle Hatlestad on December 13, 2011 at 08:48 AM CST #

I have a requirement wherein there is a metadata field called as ReportYear.
In the corresponding Standard search which is created for the profile, i need to specify ReportYear>2009 as a default value.
Can you please help me about how to achieve this in UCM 11g.

Posted by guest on February 15, 2012 at 05:55 AM CST #

In regards to the default ReportYear, you can create a Rule which has an Activation Condition to only take effect on the Search Form. Then for the fields, you can select ReportYear and in the 'Use default value' dialog you can specify the date value you want. The following is the section in the documentation on managing Rules:


Posted by guest on February 16, 2012 at 11:31 AM CST #

Post a Comment:
  • HTML Syntax: NOT allowed

Kyle Hatlestad is a Solution Architect in the WebCenter Architecture group (A-Team) who works with WebCenter Content and other products in the WebCenter & Fusion Middleware portfolios. The WebCenter A-Team blog can be found at: ateam_webcenter/


« July 2016