NetSuite’s Entity “Other Relationship” Idiosyncrasies

This article is relevant if you are considering using NetSuite’s Other Relationship feature on entity-based records.

Background

One of the major reasons the NetSuite’s architecture is powerful is because the database model attempts to build a generalized business expression of the relationship between entities and transactions.  In the case of entities, the two most common are the Customer and Vendor.   However, NetSuite extends this concept to include Contacts, Partners, and Others.   The idea is that an entity is a generalized version of these more specific types.

NetSuite allows a single entity record, as witnessed by its internalid, to be more than one of these specific types.  I love this idea as it suggests that an entity is holding more than one role in transactional constructs.  This frequently comes up in many business models.  I recall working with a client in the commodities trade where both vendors and customers were buying and selling.    When we have a single entity referencing transactions of different types (such as both revenue and costs), our reporting becomes more powerful.

NetSuite Other Relationship Considerations

NetSuite’s Other Relationship implementation produces notable challenges.  My goal here is to summarize these so that you may release possible frustration recognizing you are not alone in your attempt to use this promising feature.  Here is the consideration list:

1. Initial Type Drives Lookup: when the entity record is first created, it is specifically typed.  For example, if you use NetSuite’s lead generation forms to capture inbound records, your record will be of type Customer.  If you later add another relationship type, and you attempt to look up the record based on that type, there is a likely chance that it may not be found.  This comes up often in customization sourcing rules for creating linked lists.
2. Can Not Easily Remove Other Relationships: once you add another relationship to an existing record, you are not presented with a simple mechanism to remove that relationship.  You can, however, navigate to the subsequently added type form and delete the record — but this becomes unworkable once you have transactions against that specific entity type.  You might be able to create another specific entity record and use the duplicate management feature to migrate the transaction data.    But when I try, I get “unexpected error”.
3. No Server Side API Access: there is no mechanism via server-side SuiteScript to create the “Other Relationships”.  This can be challenging in business models that require full record automation.   There is however a mechanism to do this client-side by effectively acting on the URL that creates the Other Relationship in the browser.  Readers should reference SuiteAnswers 41804, “Automatically Create Lead/Customer after Vendor Creation and Link It to Other Relationships Field via SuiteScript”.  I wrote an article in 2015 that shows you how to do this.  See Convert a NetSuite Lead to a Vendor.  Our team has attempted to use a server-side script to call that URL, yet NetSuite is difficult to fool in that context to have it believe that the URL is being called client-side.  If you have succeeded, do indeed share with us by commenting below.
4. Multi-Subsidiary Vendor / Customer Relationships:  The ability to have a single vendor or customer work in a multi-subsidiary relationship can be meaningful, for all the same reasons we want the entity to participate in “Other Relationships”.  However, if you use “Other Relationships”, you can not use the multi-subsidiary feature;  aargh.
5. Connection to Specific Types:  the entity saved search does not allow you to connect to the attributes of the specific type.  It’s unfortunate because there are times that you need an entity related search but one element is on a customer or vendor record and you can’t act with it.  However, the new SuiteAnalytics Dataset tool does allow us to connect this information together.

Helpful Other Relationships Lookup

NetSuite presents a mechanism to lookup entities via the Entity saved search type.   The entity search allows you to return the “type” which reveals the Initial Type described above.   However, what may be less well known is that you can reference the type via a formula field, {type.id}, which returns syntax that is valuable when you are crafting lookups via SuiteScript.   Here are related articles that I have crafted that discuss aspects of the type lookup challenge:

1. NetSuite SuiteScript: Top Level Customer Lookups on Entity Records
2. NetSuite Lookup: Get Custom Record Script ID from Internal ID Integer

In a similar domain related to entity roles, I talk about how to solve the contact-to-entity relationship challenge.  See these articles:

1. NetSuite Tip: How to Update Contact to Entity Role Relationships
2. Breakthrough NetSuite’s Contact to Entity Role Relationship
3. Join Multiple NetSuite Saved Searches to Build a Data Universe

NetSuite Considerations

We can’t tell what is going on behind the scenes at the NetSuite database level.  Instead, we are given a number of views of the database via supplied Saved Search and now the Analytics environment.  At the time of this writing, Analytics is becoming more useful — although I find that when I need to serve our clients, I still start all my lookups using Saved Searches because I can’t quite act on Analytics in the customization context often required.  I suspect this will change soon.

If you found this article helpful, feel free to sign up to receive notifications as I post new ones.  If you have a specific NetSuite entity lookup challenge, let’s have a conversation.