How should I distinguish external system IDs from Busabase record IDs?

Use Busabase’s own record id as the canonical key inside Busabase, and store each upstream ticket id in dedicated Text fields on that record. Integrations should look up Busabase rows by those external-id fields (or by a composite you define), not by overwriting the Busabase id.

Where to store the external id

On the Base that represents the ticket / mirrored entity, add fields such as:

Keep the Busabase record id untouched — APIs, Relations, and Change Requests already key off it.

Which id the integration should use

1. Creating / upserting from the other system → search Busabase by externalSystem + externalId (or a single unique zendeskTicketId). If found, update; if not, create and save the external id.
2. Calling back into the other system → read externalId from the Busabase record.
3. Linking inside Busabase (Relations, workflows) → use the Busabase record id.

Several systems, possibly overlapping ids

Do not rely on a single global externalId if two tools can both issue "12345". Prefer one of:

• Separate fields per system (zendeskId, jiraKey, …), each unique within its own namespace; or
• One externalId + externalSystem, with uniqueness on the pair (and filters/views always scoped by system).

How to verify

1. Create a record with externalSystem=zendesk, externalId=1001.
2. Run your sync twice with the same ticket → you should update the same Busabase row, not create a duplicate.
3. Create another system’s ticket that also uses numeric 1001 but externalSystem=jira → it must be a different row (or a different field).

Boundaries

• Putting the external id into the Busabase primary display name is fine for humans, but still keep a dedicated field for reliable lookups.
• If you need many external keys over time, a related “External links” Base (record ↔ system ↔ id) scales better than endless columns.

If you share which systems you connect first, we can suggest a concrete field list and unique constraints for that Base.