Buyer Contacts

There are many industry contacts that have roles within the context of buyer parties. Auth Data uses the concept of an assignment to associate a contact with a buyer and articulate the function that they operate within the context of the buyer. For example, a music buyer employs an individual in charge of marketing for booked events. This individual is called a buyer contact within Auth Data.

Assignments

An :Assignment node is used to connect a party of type Contact to the party of type Buyer for whom they work for. Note that the term "works for" is not strictly defined solely as an employer-employee relationship. For example, a buyer may use a box office manager employed at a venue to validate ticket sales for a deal. While not stictly employed by the buyer, the box office manager would be assigned to that buyer in Auth Data. A partial structure of the relationship would look like this:

Job Roles

A :JobRole node is a categorical variable that allows for defining allowed jobs for a given organizational party in a particular role and role subType. The use of a subType is needed to capture different sets of roles for different types of buyers.

For example, given an organization party with a buyer role and "Touring" subType, we might have three allowed roles using the ALLOWED_JOB_ROLE relationship:

Modeling Buyer Contacts

The diagram below shows the complete picture: "Joe", a person party with a contact role, has an appointment at the "Foo Presents" organization. "Foo Presents" has a role of Buyer, subType Music, so there are three allowed job roles Joe can have for this organization: Ticketing Contact, Box Office Contact, or Promoter Contact:

Note that this means that the API must check the party referenced in the APPOINTED_TO relationship to see if the job role is allowed for the appointment's organization party, based on its role.

A complication arises when we realize organization parties can have multiple roles. For example, "Foo Presents" could conceivably also be a client, or a venue, or any other type of role that might have different allowed job roles. The roles would end up mixed together on the Appointment node in this model. And therefore, when we de-activate a role for the party, then some of the job roles may be invalidated by that de-activation. We're aware of this, but don't see it as a concern.