Skip to main content

Loading an Accord

An Accord is the primary object in the system, typically one per opportunity or customer engagement. Most integrations spend the majority of their query time on this single type and its related collections.

This page walks through fetching one Accord with everything you need to render it: the Playbook (stages and steps), the participants (members), shared content (resources and summaries), and any custom domains it's hosted on. It mirrors the query the Accord webapp uses on the Accord detail page.

What's on an Accord​

FieldTypeWhat it is
Core fieldsString, Datetime, BigFloat, …id, accountName, opportunityName, opportunityAmount, closeDate, isDraft, isTemplate, timestamps.
stages → steps[Stage] / [Step]The Playbook: ordered stages, each containing ordered steps. Steps may be internal: true (team-only) or external.
accordMembers[AccordMember]Participants on the Accord. Each links to a WorkspaceAccount (see Loading a Workspace Account) and adds Accord-specific metadata: designation, invitationStatus, internal, contactRole.
resources[Resource]Files, links, embeds shared in the Accord.
summaries → sections[Summary] / [Section]Executive summaries broken into editable sections.
accordDomains[AccordDomain]Custom domains the Accord is reachable on.

The query​

query LoadAccord($accordId: String!) {
  accord(id: $accordId) {
    # Core deal info
    id
    workspaceId
    accountName
    accountGlyphUrl
    opportunityName
    opportunityAmount
    closeDate
    isDraft
    isTemplate
    archivedAt
    createdAt
    updatedAt

    # Playbook: stages → external steps
    stages(orderBy: PRIMARY_KEY_ASC) {
      id
      title
      order
      description
      steps(
        condition: { internal: false }
        orderBy: PRIMARY_KEY_ASC
      ) {
        id
        title
        order
        # status, dueAt, owner — see the Step type in the reference
      }
    }

    # Participants — each AccordMember points at a WorkspaceAccount,
    # which we expand into the user's profile + account in the same call.
    accordMembers {
      id
      designation
      invitationStatus
      internal
      contactRole
      shouldReceiveNotifications
      workspaceAccount {
        id
        contactEmail
        role
        profile {
          firstName
          lastName
          preferredFirstName
          preferredLastName
          picture
          preferredPicture
          jobTitle
        }
        account {
          id
          email
        }
      }
    }

    # Shared content
    resources {
      id
      title
      # url, blobType, parentFolderId, internal, … see the Resource type
    }

    # Executive summaries
    summaries {
      id
      # sections { … } — see the Summary type
    }

    # Custom domains (e.g. workspace.inaccord.com or a vanity domain)
    accordDomains {
      id
      domain
    }
  }
}

Variables​

{ "accordId": "ac_01H…" }

Trimming the query​

The query above hydrates everything: useful on a detail page, expensive everywhere else. In practice you should fetch only what the screen needs.

A summary card view might be just:

query AccordCard($accordId: String!) {
  accord(id: $accordId) {
    id
    accountName
    opportunityName
    opportunityAmount
    closeDate
    overallStatus
    accordMembers(condition: { internal: false }) {
      id
      workspaceAccount {
        profile { preferredFirstName preferredLastName picture }
      }
    }
  }
}

A pipeline view that lists many Accords typically reaches for the connection:

query Pipeline($cursor: Cursor) {
  accordsConnection(
    first: 25
    after: $cursor
    orderBy: CREATED_AT_DESC
    filter: { archivedAt: { isNull: true } }
  ) {
    edges {
      cursor
      node {
        id
        opportunityName
        accountName
        opportunityAmount
        closeDate
      }
    }
    pageInfo { hasNextPage endCursor }
  }
}

See Filtering & conditions for the full filter / orderBy vocabulary.

Internal vs external steps and members​

Two booleans matter:

  • step.internal: when true, the step is only visible to the workspace's own team, not the customer. The example query above filters them out with condition: { internal: false }.
  • accordMember.internal: when true, the member is on your team (Accord workspace side); when false, they're on the customer side. Use this to split the participant list into "Us" and "Them".

Common gotchas​

  • stakeholderMap is JSON. It's a flexible blob the webapp uses for the stakeholder-map visualization. Treat it as opaque unless you've checked the current shape; it isn't strongly typed.
  • crmObject / crmId. When an Accord is linked to a CRM record (Salesforce, HubSpot), crmId points at the CRM object id. The reverse relation is exposed as connectedCrmObject.
  • accordMembers includes soft-deleted rows on the relation by default. If you only want active members, filter on deletedAt: { isNull: true }.
  • Templates. When isTemplate: true the row is a Playbook template, not a live deal. Most consumer queries should add filter: { isTemplate: { equalTo: false } }.

Where to go next​