Custom Fields vs. Custom Attributes


I’m often asked what’s the difference between Custom Fields and Custom Attributes, and when each should be used.

My answer is “Use Custom Attributes, unless you need to use the field with a feature not compatible with Custom Attributes.”

This answer baffles most. It is not clear what RightNow product features do not support Custom Attributes. The goal of this article is to identify those features and help you make better decisions when defining your data model extensions.

What is a Custom Attribute?

Custom Attributes are the core table extension feature that is compatible with the Custom Business Object. Like Custom Fields, Custom Attributes allow you to alter existing tables in the RightNow data model, including Contact, Incident, Answer, Opportunity and Organization objects. They also support the same field types as Custom Fields including Text, Text Area, Menus, Integer, Date Time, Date, and Boolean fields.

Besides the similarities, they have a few key benefits over the older Custom Fields:

  • Custom Attributes can be imported and exported, both one at a time or in large groups. This feature saves significant developer time and removes what used to be a large risk of error. With Custom Fields, you have to create each field by hand on each site clone your development team is working on – mistakes are commonly made when migrating from site to site.
  • Like Custom Business Objects, Custom Attributes need to be deployed before they are activated (and the Database is altered). These deployments can be done immediately or scheduled for a slow time (such as at night). With Custom Fields, the DB was altered when you saved your change. This could be problematic for a habitual saver. While it’s possible to queue up a bunch of Custom Field changes, if you are a neurotic saver you can inadvertently put a lot of load on the database by submitting multiple alterations with multiple saves.
  • Custom Attributes can be used to create relationships between objects in the Data Model. The relationships can be between RightNow core objects and Custom Objects (CBO as parent) or between two RightNow core objects.

Why Use Custom Attributes?

You should strive to use Custom Attributes because someday Custom Fields will go away. It is clear that Custom Attributes are a replacement for Custom Fields. Once Custom Attributes have been fully integrated into all aspects of the RightNow platform, Custom Fields will go away. I’m hoping that RightNow will have a painless (and automatic) migration procedure for these legacy fields, but I always hedge my bets with RightNow and their product decisions. Assume that you will have to manually port all of your Custom Fields over to Custom Attributes sometime in the future when you choose to do a product upgrade.

Use Custom Attributes whenever you possibly can!!!!

When Shouldn’t I Use Custom Attributes?

Do not use Custom Attributes if the field you are defining is used by a product feature that is not yet compatible with Custom Attributes. This list will change from release to release as the RightNow solution evolves. My latest experience is with a February 2013 site, so this list will be written in that context.

This list isn’t long, but it does include some very, very key features.

If you need to use Server Rules with the field

Server Rules (note: not Workspace Rules) are a very, very old feature of the solution. The underlying codebase is a mess and RightNow has been reluctant to open Pandora’s box to perform a much needed rewrite. The clock is ticking, and the time will come where it becomes a priority, but I have yet to see this happen.

Server Rules have no visibility to Custom Attributes. If anything you plan on doing with your field includes interaction with Server Rules, use a Custom Field instead.

If you need to use the field with Chat (includes proactive and form based chat)*

The RightNow chat service is disjointed from the rest of the RightNow solution. It runs on its own servers and on a completely different technology stack than the rest of the product. Because of this, Chat tends to lag behind when new features are introduced.

As of February 2013, Custom Attributes cannot be set as part of a Chat interaction. You can create a Chat Launch form that contains Custom Attribute fields, but these will never be passed to the Agent Console (On a similar note, neither can Contact Custom Fields. The only Contact fields that can be passed are First Name, Last Name and Email Address).

This also applies to Proactive Chat.

If you need to define new Incident fields that will be set in a Chat session, use Incident Custom Fields instead.

*There is a trick that can be used to enable Custom Attributes and Contact Custom Fields for a chat session. It involves a trick where you actually submit an Incident, then set an attribute on the Submit Button widget to redirect to the Chat Landing page on successful submission. The redirect will include an i_id parameter which the chat servers associate to the Chat Session. This trick only works well OOTB if the user is logged in. If they are not logged in, then some customization work is needed. This trick is beyond the scope of this article.

If you need to set the field with PTA or Encrypted PTA*

Custom Attributes are not compatible with PTA and I’m not sure if it will ever be. PTA (Pass Through Authentication) is a proprietary solution that has been part of the RightNow product for many years. It is not standard-based in any way, and is full of fun little quirks that make it hard to implement.

Recently RightNow added SAML support to Customer Portal and I see this replacing PTA in the future. At the time of this writing, RightNow’s SAML implementation doesn’t support on-demand Contact provisioning (even though SAML does have features that would enable this). Until it does, PTA will still have a place.

* PTA can be extended fairly easy to support Custom Attributes through writing a CP customization using the frameworks “Hooks” feature. There is a hook named “pre_pta_convert” that allows a developer to intercept the PTA request and run custom logic. This custom logic can include the processing of Custom Attributes passed through the PTA string.

The exact process of this customization is outside of the scope of this article. Just know that it is possible and works well with both PTA and Encrypted PTA.

Categories : 


Some further benefits of custom attributes over custom fields:

  • A menu custom attribute can use existing menus as their source, including menu custom objects. This has 2 really important benefits.
    1. You can now re-use a menu.
    2. You can use an API to add/remove items from a custom object which implements menu (not sure if this can be done with the simpler menu custom objects).
  • Custom Attributes can be namespaced, making it easier to track & maintain them, as well as for 3rd parties building packaged solutions.
  • With newer versions of the Connect Web Services API, it has become easier to work with Custom Attributes rather than Custom Fields. See

Ryan, you bring up some good points and have reminded me that I need to update this article based on some new findings, specifically around menus.

I now recommned not using CA's for menus unless you have a use case that specifically calls for the menu items to be used in multiple places (multiple fields, or multiple objects). This is because a Custom Attribute Menu field HAS to be indexed. Since you have a limit on the number of indexes you can have on an object, this is rather important. A Custom Field menu, on the other hand can be optionally indexed. Keep this in mind when designing a solution as this can catch you by suprise and is rather hard to undo.

Also, I wouldn't say that Custom Attributes are becoming easier to work with. They are still a giant pain in the ass (but thankfully Jack has a rather nice abstraction for setting them). Instead I'd say that Custom Fields have become as hard to set as Custom Attributes.

Zircon - This is a contributing Drupal Theme
Design by WeebPal.