External Record

Description

A connection from a Party to a corresponding record in an external system. These can be non-UTA systems (e.g. Variety, IMDB, or Instagram), or internal systems (e.g. NetSuite, uTour, or Onyx). External Record have a platform-specific unique id (platformId) like an IMDB ID or a Netsuite ID.

External Records have a complex DMO Lifecycle and have Third Party Data Integrations.

Label

:ExternalRecord

Properties

Property	Description	Type
id	Unique identifier for this ExternalRecord node. A uuid. Note: This is not the actual ID on the external system, instead that is platformId.	string
type	The type of external record (see table below)	string
platformId	The platform's unique identifier for this record	string
originalUrl	The original URL to this external record when it was first entered by DMO	string
primary		boolean
createdBy	the person or process that created the node	string
createdDate		dateTime
modifiedBy	the person or process who last modified the node	string
modifiedDate		dateTime

The naming convention for External Record type is to use the name of the platform if there is only a single type of ID stored on that platform (Ex: Instagram uses only one type of ID, so the type within Auth Data would simply be "Instagram").

In the cases where there are multiple IDs within the same platform, the name of the ID within Auth Data would be the name of the platform followed by the ID name. For example, UTour uses multiple IDs to represent artists and businesses. In this case the type name would be "UTourArtistId" and "UTourBusinessId".

In the case where a platform has multiple subsystems, we would add the name of the system into the type name. For example, the Airtable platform hosts multiple airtables, such as the "Festivals" airtable, each with their own IDs. In this case, the name of the airtable would be added to the type as such: "AirtableFestivalsEventSeriesId" and "AirtableFestivalsEventInstanceId".

Below are the External Record types:

Type Name	Notes
IMDB
Variety
Pollstar
Rostr
TMID	Tribune
MHID	MediaHound
MH_AltId	MediaHound
X	(formerly Twitter)
Facebook
Instagram
YouTube
Spotify
TikTok
Twitch
Kick
Deezer
Pandora
Soundcloud
Snapchat
LinkedIn
Threads
Bluesky
AppleMusic
BandsInTown
Onyx
Google Maps	PlaceID
NetSuite	Key used in the accounting system
UTour	Key used in legacy touring application
UTAEmpId	UTA employee ID, coming from Workday
UTAWorkdayId	UTA workday ID, coming from Workday
UTAAvalonId	Avalon ID as stored in Netsuite
UTourAristId	UTour artist ID in format stored within NetSuite
UTourBusinessId	UTour business ID in format stored within NetSuite
FestivalsAirtableEventSeriesId	Key used within Festivals & Fairs airtable for an EventSeries
FestivalsAirtableEventInstanceId	Key used within Festivals & Fairs airtable for an EventInstance
USEIN	United States Employer Identification Number
CRN	Company Registration Number, business ID where it is legally registered
VAT	Value Added Tax identifier

Key

id: Remember this is an internal identifier and not the platform-specific id, which is stored as platformId.

Relationships

The HAS_EXTERNAL_RECORD relationship connects parties, venue, or event series to external ids.

Examples

Create a new IMDB external Record for an existing party

MATCH   (party:Party { id: $id })
MERGE   (party)-[rel:HAS_EXTERNAL_RECORD {
          active: true,
          private: false,
          fromDate: date()
        }]->(e:ExternalRecord {
          id: "<uuid>",
          type: "IMDB",
          originalUrl: "https://www.imdb.com/name/nm0749263/"
          platformId: "nm0749263"
        })
RETURN  party.id,
        party.name,
        e{.*}

DMO Lifecycle

External records have a complex DMO Lifecycle. There are 2 categories of external systems

1. External Systems easily anchored in Platform Ids

Systems where it is easy to find a record's internal identifier. This is typically internal services like Netsuite or Onyx. Our DMO team or data ingestion team can simply map Parties to the external identifiers directly. In this case, the DMO would create :ExternalRecord nodes with the correct platform type and set the platformId directly.

2. External Systems accessible through URLs

Most external systems and social services expose records through URL systems. These external systems typically have internal identifiers for these records but they may be tricky or time consuming to obtain. Additionally these services typically have multiple valid urls for a record. There is often not a single canonical URL for a record. Also consider that URLs for records typically include volatile identifiers like a username or handle. Users can change these, so URLs are not stable over time. This poses a DMO challenge.

For these types of systems, the DMO team will create an :ExternalRecord node with the correct platform type and set the originalUrl directly. They will leave the platformId unset. The naming implies that this URL is not guaranteed to be accurate— it was the correct url for this external system at the time the DMO created the record.

Next, an asynchronous process will observe these newly created :ExternalRecord nodes with an originalUrl but no platformId. This process will trigger a resolver process where a source-specific service will translate the originalUrl into a unique, durable platform identifier. That value will be written onto the :ExternalRecord node's platformId property. Depending on the platform, this process may be rate-limited or time-intensive so there is an arbitrary amount of time before an originalUrl will be mapped to a platformId.

Some platforms have usernames or handles as well. These values will be extracted during the resolver process. The values, however, will not be stored in Auth Data. To access these values and other platform-specific data see the Third Party Data Integrations section.

Third Party Data Integrations

From the Auth Data perspective, Parties are linked to External Records. It is only concerned with the mapping of a party to an external system. Data from that external system lives elsewhere. However, applications and services often want this additional information. Using our federated GraphQL platform, you can easily access this data along with Party data.

The Third Party Data Subgraph provides this data.

Here is an example GraphQL query:

lookupClients(ids: $ids) {
  id,
  name,
  externalRecords {
    id # Internal Auth Data UUID for this :ExternalRecord node
    type # The platform type
    originalUrl # The original URL for this record entered by DMO. Typically this should not be used or referenced
    platformId # The platform-specific identifier

    # The `profile` field is provided by uta-tpd-subgraph through federation
    profile {
      id # The platform-specific identifier. Repeated for convenience
      type # The platform type. Repeated for convenience.
      name # The name of this record according to this external system
      url # The current URL for this record on the external system
      username # The current username/handle for this record on the external system
      isVerified # Whether this profile has been verified on the external system

      ... # Other datapoints from this external system. See the full docs for what is accessible
    }
  }
}