Applies to: CaseForge 3.x · Owner: CaseForge Implementation Engineer · Last reviewed: March 2025

Integration Checklist

Use this checklist during Phase 2 of the implementation (weeks 3–4). Work through each section with the customer IT administrator. Mark items complete only after end-to-end testing.

How to use this checklist: Complete sections in order. Log blockers in the shared project tracker immediately. Items marked Required must be complete before go-live. Items marked Conditional apply only if that integration is in scope.

1. Network and access prerequisites

  • Required CaseForge tenant URL is accessible from the customer network (no proxy or firewall blocking outbound HTTPS)
  • Required CaseForge IP ranges added to customer allowlist (if egress filtering is in use)
    CaseForge IP ranges: 34.120.0.0/16, 34.149.0.0/16. Confirm with the IE that these are current — ranges may change with 30-day notice.
  • Required Customer admin account activated and password changed from temporary credential
  • Conditional Dedicated service account created in customer directory (required for LDAP sync or on-premises document storage)
  • Conditional Outbound webhook endpoint accessible from CaseForge (required if customer will receive webhook events)

2. Single sign-on

Complete the SSO section before configuring user sync. SSO must be working before you can verify that synced users can log in.

2.1 SAML 2.0

  • CaseForge Service Provider metadata XML provided to customer IT admin
  • SAML application created in the customer IdP (Okta, Azure AD, ADFS, or other)
  • IdP metadata XML or metadata URL provided to CaseForge IE
  • Attribute mappings confirmed:
    CaseForge fieldMapped to IdP attribute
    Email
    First name
    Last name
    Groups
  • SSO login tested with at least one pilot user — login completes without error
  • SSO login tested with a user who is not assigned the CaseForge application — access denied as expected
  • SSO enabled for the production tenant

2.2 OIDC

  • Redirect URI provided to customer IT admin: https://[tenant].caseforge.io/auth/callback
  • OIDC application created in the customer IdP; discovery endpoint URL provided to CaseForge IE
  • Client ID and client secret configured in CaseForge tenant settings
  • OIDC login tested with a pilot user — login completes without error
  • Token expiry and refresh behavior confirmed (default: 60-minute session, 24-hour refresh token)

2.3 Post-SSO verification

  • User can reach the CaseForge tenant via SSO without entering a separate CaseForge password
  • SSO-provisioned user appears in the CaseForge admin user list with correct name and email
  • Deprovisioning tested: user removed from IdP application; CaseForge session terminates and re-login denied

3. User directory sync

  • Conditional Active Directory or LDAP sync configured (required for on-premises AD)
    • LDAP server hostname and port provided to CaseForge IE
    • Service account DN and password configured in CaseForge
    • Sync filter confirmed (which OUs or groups to sync)
    • Initial sync completed — user count in CaseForge matches expected count
    • Incremental sync verified
  • Conditional SCIM provisioning configured (for Okta, Azure AD, or SCIM-capable IdP)
    • SCIM endpoint URL and bearer token provided to customer IT admin
    • SCIM application configured in the IdP
    • Test user pushed via SCIM — appears in CaseForge with correct attributes
    • Test deprovision — user deactivated in IdP; CaseForge account deactivated within one sync cycle
  • Group-to-role mapping confirmed:
    IdP groupCaseForge role

4. Email

  • Required Outbound email method selected: CaseForge-managed relay (default) or customer SMTP
    If using customer SMTP: SMTP hostname, port, and auth credentials provided to IE; credentials entered in CaseForge tenant settings; test email sent and delivered.
  • Required Notification sender address confirmed
  • Required SPF and DKIM records added to the customer's DNS (IE provides the required record values)
  • Test notification email delivered to at least three different recipient email addresses, including one on a different domain
  • Notification emails not landing in spam

5. Document storage

5.1 CaseForge-managed storage (default)

  • Customer confirmed that CaseForge-managed storage (S3-backed, encrypted at rest) is acceptable
  • Data residency region confirmed and configured (US-East, EU-West, or APAC)
  • Storage quota reviewed and appropriate plan confirmed

5.2 Customer-provided storage

  • Conditional SharePoint Online: site URL confirmed; Azure app registration granted Files.ReadWrite.All; OAuth consent completed; test upload and retrieval confirmed
  • Conditional Amazon S3: bucket name and region provided; IAM policy applied with s3:GetObject, s3:PutObject, s3:DeleteObject; bucket encryption confirmed; test upload and retrieval confirmed
  • Conditional Google Drive: Shared Drive ID provided; CaseForge service account granted Contributor access; test upload and retrieval confirmed

6. CRM integration (conditional)

6.1 Salesforce

  • Salesforce org type confirmed: Production or Sandbox
  • Connected app created with api, refresh_token, offline_access OAuth scopes
  • Consumer key and secret provided to CaseForge IE
  • OAuth flow completed; CaseForge can query Salesforce contacts and accounts
  • Field mapping confirmed; test case created and linked Salesforce contact displays correctly

6.2 HubSpot

  • HubSpot portal ID confirmed
  • Private app token created with crm.contacts.read and crm.companies.read scopes
  • Token provided to CaseForge IE and configured in tenant settings
  • Test case created; linked HubSpot contact displays correctly

7. Ticketing integration (conditional)

7.1 Jira

  • Jira instance URL confirmed (Cloud or Server/Data Center)
  • API token generated; provided to CaseForge IE
  • CaseForge connection tested: can read Jira project list
  • Default Jira project confirmed; field mapping confirmed
  • Test ticket created from a CaseForge case — appears in Jira with correct field values
  • Jira status change syncs back to CaseForge case timeline

7.2 ServiceNow

  • ServiceNow instance URL confirmed
  • Integration user account created with itil role; credentials provided to CaseForge IE
  • Test incident created from CaseForge — appears in ServiceNow
  • Incident resolution in ServiceNow triggers status update in CaseForge

8. Webhooks (conditional)

  • Webhook endpoint URL provided by the customer (HTTPS required)
  • Endpoint returns HTTP 200 within 10 seconds
  • Webhook secret configured; customer confirms payload signature validation is implemented
  • Test event triggered; customer confirms payload received and signature verified
  • Event subscriptions confirmed: case.created · case.status_changed · case.assigned · case.closed · case.document_uploaded

Sign-off

Before proceeding to Phase 3, both parties must confirm that all Required items are complete and all in-scope Conditional items are complete or have an agreed resolution date.

SectionStatusNotes
Network and access prerequisites
SSO
User directory sync
Email
Document storage
CRM integration (if applicable)
Ticketing integration (if applicable)
Webhooks (if applicable)
Customer IT admin: Date:
CaseForge IE: Date: