Routing HubSpot Custom Objects

What Distributely can route

Out of the box, a team can be pointed at any of the standard HubSpot objects: Contact, Company, Ticket, Deal, and Lead. You pick one in the Object Type field when you edit a team.

Custom objects work the same way, with one extra step first. You register the object once in Settings. After that it behaves like any other object type.

Registering a custom object

Go to Settings and open the Manage Custom Objects card. Make sure the portal shown at the top is the right one, then fill in the form.

• Display Name — what you want to call the object inside Distributely. This is the label people see in dropdowns. Example: Appointments.
• HubSpot Object Type ID — the identifier HubSpot uses for the object, in the form 2-12345678. You can find it in HubSpot under the object's settings, or in the URL when you view the object's records. This has to be exact. It is how Distributely maps a record back to the right object.
• Internal Object Key (optional) — a short key used internally. Leave it blank and Distributely derives one from the display name.
• Default Owner Property (optional) — the property on this object that owners are written to, if it is not the standard one. 
• Active — leave this checked. Only active custom objects appear in team dropdowns.

Click Add Custom Object. The object appears in the Configured Custom Objects table, where you can edit or delete it later.

What registering unlocks:

Once the object is registered and active, three things become possible.

1. The object shows up in the Object Type dropdown when you edit a team, alongside the standard objects.
2. That object's HubSpot properties become selectable when you build team rules, so you can route on the object's own fields rather than on a related contact or deal.
3. Distributely recognises records of that object when they reach it from a HubSpot workflow, and reads and writes the right object in HubSpot.

Deleting a custom object from this screen removes the registration, not the HubSpot object or its records. Any team still pointed at it will stop matching records.

Worked example

Say you run a services business. HubSpot has a custom object called Appointments, and you want each new appointment routed to a field technician.

Step 1 — find the object type ID in HubSpot. In the Appointments object settings, the identifier looks like 2-45881230.

Step 2 — register it. In Distributely, go to Settings, open Manage Custom Objects, and enter Appointments as the Display Name and 2-45881230 as the HubSpot Object Type ID. Leave Internal Object Key blank. Leave Active checked. Click Add Custom Object.

Step 3 — build the team. Create a team called Field Technicians. Edit it and set Object Type to Appointments. Add your technicians as members and pick an owner selection method.

Step 4 — write the rules. Open Configure Rules for that team. The properties list now shows Appointment properties, so you can build a rule such as service type is equal to Installation.

Step 5 — check where the owner lands. The team's Owner Property field now lists Appointment properties. Leave it on the default if the object uses the standard owner property. If the object carries its own owner-type property, select that one instead.

Step 6 — wire it up in HubSpot. Build a workflow on the Appointments object, enrol the records you want routed, and add the Distributely action. When an appointment enrols, Distributely matches it to the registered object, picks the Field Technicians team, selects a technician, and writes that owner onto the appointment record.

FAQ

Where do I find the HubSpot object type ID?

In HubSpot, open the custom object's settings. The identifier is the one that starts with 2- followed by a number. Copy it exactly. A wrong ID means records never match the registration.

Can two teams route the same custom object?

Yes. Set both teams to that Object Type and use team rules and team order to decide which one handles a given record.

Do custom objects support the same owner selection methods?

Yes. Round robin, weighted, and attribute-based selection all work the same way once the object type is set on the team.

What happens to a custom object record if no team matches it?

The same thing that happens for a standard object. The team fallback behavior runs first, then the portal fallback owner. See Fallback Behavior and Portal Settings and the Fallback Owner.