Are External worker / External position / External organisation intentionally not ingestible via third-party Teamwork Graph connectors?

Rovo
1

The Teamwork Graph API reference documents the ExternalWorker, ExternalPosition, and ExternalOrganisation object types (with HR relationships such as external_worker_fills_external_position and external_position_manages_external_position). However:

  1. These three types do not appear in the connector object types reference, nor in the connector-to-API mapping table on “Querying data from Forge connectors”.
  2. The @forge/teamwork-graph SDK’s object type union does not include them.
  3. When we experimentally sent atlassian:external-worker via graph.setObjects() from a graph:connector app, the server rejected it with “Unsupported entity type provided!”.

So empirically these types look like read-only “vessels” that only Atlassian’s first-party HR integrations (Atlassian Home org data) can populate. But I couldn’t find this stated anywhere in the docs.

Questions:

  1. Is it correct — and intentional — that third-party Forge connectors cannot ingest these HR object types?
  2. Is there any roadmap to open them (worker / position / organisation) to third-party connectors? Our use case is syncing an HR master (departments, positions, reporting lines, concurrent posts) from a customer’s HR system into Teamwork Graph so Rovo can answer org-structure questions.
  3. If they remain first-party only, what is the recommended pattern for org-structure data from a third-party connector? We currently work around it with atlassian:customer-org (+ Groups) for departments and atlassian:document for person profiles, which works but loses the position / reporting-line semantics.

If this is by design, it would be helpful if the docs said so explicitly on the API object type pages (e.g., “populated by Atlassian HR integrations only; not available as a connector object type”).

2

Your three checks hold up. There is no worker, position or organisation row in the mapping table on querying-ingested-data, and no such member in the Object union of the current @forge/teamwork-graph types. Same wall. The server rejection is it.

HR data has a different door today. The Teamwork Graph HRIS S3 connector imports positions, workers and organizations from three CSVs in an S3 bucket, org-admin config, and staff in topic 102459 drew that line between Forge connectors and the Atlassian-built one. Field reference per file: Connect HRIS S3 data to your Teamwork Graph | Atlassian Support

For the HR-master case I’d stop bending customer-org + document. Export to those CSVs, let the org admin wire the connector, reporting lines survive. Rovo reading it? Not checked, the docs only name Talent.

First-party-only or not is a staff question. Can the HR system drop CSVs into S3 on a schedule?

3

Thanks Mihai — the HRIS S3 pointer was the missing piece. We’ve been through the setup guide and the field reference.

To answer your question: technically yes — and in our case there is no commercial HRIS at all: our Forge app is the HR master (departments, positions, reporting lines, concurrent posts are managed in-app). Generating the three CSVs from that master is straightforward, and the schema mostly fits: superiorOrganizationId covers the org tree, and concurrent posts fall out naturally since positions.csv points at workerId, so one worker can hold N position rows.

One schema gap for anyone else evaluating this route: there is no position→position reporting line in the CSVs — external_position_manages_external_position exists in the API reference, but the only manager semantic expressible via CSV is organizations.managerPositionId.

What’s still open on our side (we’ll verify on a dev org unless someone already knows):

  1. The docs say HRIS data will not appear in unified search and only “may” surface standard fields to Rovo — whether Rovo Chat can actually answer org-structure questions from it.
  2. Whether the ingested ExternalWorker / ExternalPosition / ExternalOrganisation objects are readable through the Teamwork Graph API from a Forge app, or scoped to first-party consumers (Talent).

And +1 on your point that first-party-only-or-not needs a staff answer — if anyone from Atlassian can confirm that (and the third-party readability of HRIS-ingested objects), it settles the architecture choice for us.

4

Thanks. On Rovo Chat the only primary line is the one you pointed at (“may subsequently provide employee-related search results by surfacing standard field HRIS information to Rovo”). I missed that last time. Hedged, and it never names Rovo Chat or org structure.

Forge reads are still open. The object-types reference lists ExternalWorker/Position/Organisation with nothing type-specific beyond the API-wide EAP and test-org rule. The HRIS doc scopes the data to “Atlassian apps like Talent”.

@forge/teamwork-graph get* calls only fetch your own connection’s objects by externalId, so reading HRIS data means GraphQL/Cypher under read:graph:*. There’s also TalentWorker and TalentPosition in the reference and nothing says which set HRIS S3 lands in. I’d query both.

Staff in 102459 treated HRIS S3 as Atlassian-built. Could someone from the Teamwork Graph team confirm?

5

Thanks for the additional context. Since your Forge app is the HR master and you can generate the CSVs, I’ll check the remaining points with the owning teams:

  • Which graph types HRIS S3 populates, and whether third-party Forge apps can query those records.
  • Whether Rovo Chat supports org-structure questions using that data.

One thing to clarify regarding your earlier document / customer-org workaround: the Forge connector module docs currently restrict HRIS data, regardless of the object type used. I’ll confirm the guidance and whether there are any plans for direct Forge support. That restriction is separate from the Atlassian-built HRIS S3 route you’re now evaluating.