Ellipse Gradient for Header

Skedulo Integration Guide

Connect Skedulo workforce scheduling data with enterprise applications through its GraphQL API, token-based authentication, and selected webhook-style notifications.

Skedulo integration options at a glance

Skedulo’s primary documented integration surface is its GraphQL API, which supports queries and mutations for Jobs, Resources, Users, Locations, Allocations, and related workforce data. Martini can consume these operations from workflows, apply filters and pagination, transform responses, and expose APIs that coordinate Skedulo with other applications. Skedulo also supports webhook-style or event notifications for selected changes, although coverage must be confirmed for each object and event. Integrations generally use OAuth-style authorization or bearer access tokens, with tenant and role permissions controlling access. A general-purpose REST API, bulk API, file API, and direct database access were not confirmed.

Integration pointSupported by Skedulo?Common use casesHow Martini supports it
GraphQL APIsYesQuery and mutate Jobs, Resources, Users, Locations, Allocations, and related scheduling data, including filtered and paginated retrieval.Martini can consume Skedulo GraphQL queries and mutations from workflows, map responses, apply business rules, and expose orchestration APIs.
Webhooks / outbound callbacksLimitedReceive notifications for selected object changes or operational events where the tenant and event type support webhook-style delivery.Martini can expose a receiving API, validate payloads, apply idempotency checks, and start a workflow. Event coverage must be confirmed per object and event.
AuthenticationYesUse OAuth-style authorization, bearer access tokens, tenant settings, and role or permission controls for API access.Martini can store credentials and tokens in secure environment configuration or secrets management and apply them to outbound API requests.
REST APIsNot confirmedA general Skedulo REST API with equivalent coverage to GraphQL was not confirmed and should not be assumed for new integrations.Martini can consume REST APIs when a specific Skedulo tenant documents one, but the integration should default to the confirmed GraphQL surface.
Bulk / async / batch APIsNot confirmedA general-purpose bulk API was not confirmed. Large transfers should use paginated GraphQL queries, incremental criteria, and bounded batches.Martini can orchestrate controlled batches, persist checkpoints, and retry or resume failed pages without requiring a bulk endpoint.
File / attachment APIsNot confirmedA general-purpose Skedulo file or attachment API was not confirmed in the reviewed documentation.Martini can process files when a separately documented tenant endpoint or external file exchange is available, but it should not assume GraphQL provides general file handling.
Database / analytics accessNoDirect access to Skedulo’s underlying database or analytics store was not identified as a supported integration mechanism.Martini should use supported Skedulo APIs and can write the resulting data to an approved database or analytics platform.

How Skedulo exposes data and business events

Skedulo GraphQL APIs

Skedulo’s GraphQL API is the primary documented integration surface. It supports queries and mutations for workforce and scheduling objects such as Jobs, Resources, Users, Locations, and Allocations, with field selection, filtering, and pagination used to control response size.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates to the Skedulo API, submits a version-controlled query or mutation, checks both transport and GraphQL response errors, maps the result into a canonical model, and invokes downstream APIs or writes to a database. For synchronization, the workflow stores a durable checkpoint and processes bounded pages rather than assuming one request returns the complete dataset.

Implementation sequence

Authenticate the workflow with the tenant-approved Skedulo token configuration
Submit the required GraphQL query or mutation with bounded fields and filters
Check transport status and GraphQL errors before processing the response
Map Jobs, Resources, Allocations, or related objects to the target model
Apply validation, scheduling, and idempotency rules
Write the result to the downstream system and store the synchronization checkpoint

Skedulo webhook-style notifications

Skedulo supports event-driven or webhook-style notifications for selected changes and notifications. Availability is not universal, so the supported object, event, payload, delivery behavior, and tenant configuration must be confirmed before implementation.

Martini implementation pattern

Martini implementation pattern: expose a controlled API endpoint for the supported Skedulo notification, validate authentication and payload structure, derive an event or business key, reject duplicates, and start a workflow. The workflow can retrieve the current Skedulo object through GraphQL before updating downstream systems, which helps avoid relying on incomplete notification payloads.

Implementation sequence

Confirm the supported Skedulo object and event for the target tenant
Receive the notification at a protected Martini API endpoint
Validate the payload and authenticate the notification source
Check the event or object identifier for duplicate processing
Retrieve the current Skedulo object when the notification is incomplete
Apply business rules and map the change to downstream systems

Common Skedulo integration patterns

Pattern 1: Create Skedulo Jobs from service requests

When to use this pattern

Use this pattern when a CRM, service platform, or ERP creates a request that must become scheduled field work. Martini validates the source request, confirms customer and location data, applies service eligibility rules, and creates or updates a Skedulo Job through GraphQL. A correlation key prevents duplicate Jobs when the source system retries.

Integration direction
Salesforce
Martini
Skedulo
Example Mapping
Skedulo FieldCanonical FieldTarget Field
Service request identifierexternalRequestIdJob external reference
Customer accountcustomerIdJob customer
Service locationlocationJob Location
Preferred service windowrequestedTimeWindowJob scheduling fields
Martini implementation pattern

A Martini workflow receives an API request or scheduled source record, validates required fields, resolves the Skedulo Location, maps service requirements, and submits a GraphQL mutation. It records the returned Job identifier, routes validation failures separately, and retries only transient API or throttling failures.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize assignments to enterprise systems

When to use this pattern

Use this pattern when downstream applications need current Job, Resource, and Allocation information. Martini periodically retrieves changed data with paginated GraphQL queries, normalizes timestamps and time zones, enriches assignments with User or Territory data, and updates the target system. Checkpoints and stable identifiers support restartable synchronization.

Integration direction
Skedulo
Martini
ServiceNow
Example Mapping
Skedulo FieldCanonical FieldTarget Field
Job IDworkOrderIdServiceNow work order reference
Resource IDassignedResourceIdAssigned technician
Allocation start timescheduledStartPlanned start
Allocation end timescheduledEndPlanned end
Martini implementation pattern

A scheduled Martini workflow reads bounded pages, applies an incremental filter or tenant-supported change marker, joins related Jobs, Resources, and Allocations, and writes idempotent updates. Failed pages are recorded with checkpoint context so the workflow can retry without replaying successful updates.

Martini capabilities used
  • scheduled workflows
  • GraphQL API consumption
  • pagination orchestration
  • data transformation
  • checkpoint handling

Pattern 3: Distribute Job event notifications

When to use this pattern

Use this pattern when supported Skedulo events should trigger notifications or business actions in collaboration, support, or customer-facing systems. Because event coverage is selected rather than universal, the workflow first validates the event type and then retrieves current Job data when the notification does not contain sufficient detail.

Integration direction
Skedulo
Martini
Microsoft Teams
Example Mapping
Skedulo FieldCanonical FieldTarget Field
Job IDjobIdMessage correlation reference
Job statusjobStatusNotification status
Assigned ResourceassignedResourceMessage assignee
Scheduled startscheduledStartNotification appointment time
Martini implementation pattern

Martini receives the supported callback, authenticates and validates it, performs a duplicate check, and queries Skedulo for current state when necessary. Business rules determine the recipient and message content, while transient delivery failures are retried and invalid events are moved to an operational error path.

Martini capabilities used
  • API exposure
  • webhook reception
  • workflow orchestration
  • business rules
  • retry handling

Pattern 4: Reconcile Skedulo scheduling data for reporting

When to use this pattern

Use this pattern when operations teams need reporting, historical analysis, or reconciliation between planned work and source transactions. Martini retrieves paginated Jobs, Resources, Allocations, Territories, and Locations, transforms them into a reporting schema, and writes them to a database or analytics service. Duplicate detection and checkpointing make recurring extracts restartable.

Integration direction
Skedulo
Martini
PostgreSQL
Example Mapping
Skedulo FieldCanonical FieldTarget Field
Job IDjobKeyjob_key
TerritoryserviceTerritoryterritory_code
Resource IDresourceKeyresource_key
Allocation statusassignmentStatusallocation_status
Martini implementation pattern

A scheduler-triggered Martini workflow retrieves bounded pages, normalizes local scheduling times, validates relationships between Jobs and Allocations, and writes upserts to the reporting store. Reconciliation rules flag missing assignments or stale records, while page-level errors are logged with correlation identifiers for retry.

Martini capabilities used
  • scheduler triggers
  • GraphQL API consumption
  • mapping and transformation
  • database integration
  • monitoring and error handling

Applications commonly integrated with Skedulo

Skedulo can be integrated with customer, service, enterprise resource planning, collaboration, and work-management applications. The exact object coverage depends on the Skedulo tenant, enabled modules, and whether the deployment is Salesforce-based or standalone, so each implementation should validate the target schema and supported operations.

Application Scenario Direction Martini Pattern
Salesforce Synchronize Accounts, Contacts, service requests, field-service Jobs, assignments, and completion updates between CRM and workforce scheduling. Salesforce → Martini → Skedulo A Martini workflow receives or retrieves Salesforce service data, validates customer and location information, maps it to a Skedulo Job mutation, and later synchronizes assignment or completion data back through a separate workflow.
ServiceNow Convert incidents, work orders, or customer-service tasks into scheduled field Jobs and return assignment or completion status. ServiceNow → Martini → Skedulo Martini orchestrates ServiceNow API calls and Skedulo GraphQL mutations, applies job-creation rules, stores cross-system identifiers, and handles retries for transient failures.
NetSuite Coordinate customer, order, asset, billing, and financial processes with field-service execution and completion status. NetSuite → Martini → Skedulo A scheduled or event-driven Martini workflow retrieves eligible NetSuite service work, enriches it with customer and location data, creates or updates Skedulo Jobs, and sends completion information back to NetSuite.
SAP Connect service orders and customer master data with Skedulo workforce scheduling and execution. SAP → Martini → Skedulo Martini consumes SAP service-order data through the interfaces exposed by the customer environment, maps it into Skedulo GraphQL mutations, and synchronizes Allocations or completion status back to SAP.
Microsoft Dynamics 365 Synchronize accounts, cases, work orders, and field-service scheduling information across customer and operations teams. Microsoft Dynamics 365 → Martini → Skedulo Martini maps Dynamics 365 work-order data into Skedulo Jobs and maps Skedulo Resources and Allocations into Dynamics 365 updates, with validation and idempotent correlation keys.
Jira Create or update engineering and technical follow-up work when field Jobs require product or operational investigation. Skedulo → Martini → Jira A Skedulo event or scheduled query starts a Martini workflow that evaluates Job status and requirements, creates a Jira issue when rules match, and synchronizes selected status changes.
Zendesk Link customer support tickets with field Jobs and return scheduling or completion updates to support agents. Zendesk → Martini → Skedulo Martini validates Zendesk ticket details, creates or updates a Skedulo Job through GraphQL, stores the cross-reference, and posts assignment or completion updates back to Zendesk.
Microsoft Teams Notify dispatchers, supervisors, or field-service groups about Job assignments and operational changes. Skedulo → Martini → Microsoft Teams Martini receives a supported Skedulo notification or runs a scheduled reconciliation, applies notification rules, formats a concise operational message, and sends it to the appropriate Teams destination.

How to build a Skedulo integration in Martini

Objective

Establish secure, tenant-specific access to Skedulo before designing the workflow.

Instructions in Martini

  • Obtain the Skedulo API endpoint, OAuth or token configuration, tenant identifiers, and required permissions.
  • Store client credentials, bearer tokens, and other secrets in Martini environment configuration or secrets management.
  • Confirm whether the target tenant is Salesforce-based or standalone and validate available objects and operations.

Objective

Select an event-driven, API-led, or scheduled trigger appropriate to the synchronization requirement.

Instructions in Martini

  • Use a supported Skedulo webhook-style notification when the required object and event are available.
  • Use a Martini API for source-system requests such as Job creation.
  • Use a scheduler for polling, incremental synchronization, reporting, or reconciliation.

Objective

Receive or query the minimum Skedulo data required for the business process.

Instructions in Martini

  • Submit narrowly scoped GraphQL queries with explicit fields, filters, and pagination.
  • Retrieve current Jobs, Resources, Allocations, Locations, or related objects when an event payload is incomplete.
  • Persist durable checkpoints for recurring or multi-page synchronization.

Objective

Coordinate Skedulo operations with validation, enrichment, target calls, and operational controls.

Instructions in Martini

  • Route the request through a Martini workflow with explicit success, validation, and technical-error paths.
  • Enrich Jobs with Locations, Resources, Users, Territories, or source-system data when required.
  • Use correlation identifiers and bounded concurrency to control processing.

Objective

Convert Skedulo GraphQL structures into canonical and downstream application models.

Instructions in Martini

  • Map Job, Resource, Allocation, User, Territory, and Location fields to the target schema.
  • Normalize timestamps and preserve relevant local time-zone context for scheduling workflows.
  • Handle optional fields and tenant-specific object differences without failing unrelated records.

Objective

Enforce business and data-quality rules before creating assignments or publishing updates.

Instructions in Martini

  • Validate required customer, location, service, and scheduling information.
  • Apply rules for eligible territories, assignment status, duplicate events, and downstream notification recipients.
  • Separate GraphQL validation errors from business-rule failures and route them for review.

Common Skedulo data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
JobsRepresent work orders or field-service assignments that must be scheduled, executed, rescheduled, or completed.Salesforce, ServiceNow, NetSuite, SAP, Microsoft Dynamics 365, ZendeskMartini queries or mutates Jobs through GraphQL, validates required customer and location data, maps fields to target work-order models, and uses stable identifiers for idempotency.
ResourcesRepresent field workers, vehicles, equipment, or other schedulable resources.Salesforce, Microsoft Dynamics 365, reporting databases, customer portalsMartini retrieves Resources with relevant availability or assignment context, normalizes workforce attributes, and synchronizes resource status or assignment information downstream.
UsersRepresent Skedulo platform users and workforce participants with tenant permissions and roles.Identity platforms, Salesforce, ServiceNow, reporting platformsMartini uses Users for ownership, dispatch, authorization, or reporting mappings while respecting tenant permissions and avoiding unnecessary sensitive data in logs.
TerritoriesDefine geographic or operational areas used for planning, dispatch, and assignment.CRM platforms, ERP platforms, reporting databasesMartini maps Territories to regional or service-area structures, applies routing or ownership rules, and preserves source identifiers for reconciliation.
LocationsIdentify customer, service, work, or dispatch locations associated with Jobs.Salesforce, ServiceNow, NetSuite, SAP, customer portalsMartini validates addresses and time-zone information, maps location identifiers and coordinates where available, and links Locations to Jobs or downstream service objects.
AllocationsConnect Jobs with Resources over scheduled time periods and represent assignment information.Salesforce, Microsoft Dynamics 365, ServiceNow, reporting and analytics platformsMartini queries Allocations with Jobs and Resources, normalizes scheduled timestamps and time zones, detects changes, and updates downstream assignment status idempotently.

Authentication and security considerations

Token-based access

Skedulo integrations generally use OAuth-style authorization and bearer access tokens. The exact grant, token endpoint, scopes, and permission model should be confirmed for the target tenant.

Tenant and role permissions

Tenant, organization, user, and role permissions determine which Jobs, Resources, Users, Locations, Allocations, and operations an integration can access.

Martini configuration

Store Skedulo endpoints, client credentials, tokens, and tenant-specific settings in Martini environment configuration or secrets management rather than embedding them in workflow definitions.

Controlled API exposure

When receiving Skedulo notifications, expose only the required Martini API endpoint and validate the notification source, payload, event identity, and authorization before starting a workflow.

Operational considerations for Skedulo integrations

Pagination and checkpoints

GraphQL responses may be bounded. Use explicit pagination, incremental criteria where available, and durable checkpoints for recurring synchronization.

Rate limits and retries

Confirm Skedulo tenant limits and use bounded concurrency with exponential backoff for throttling and transient server failures. Handle authentication, validation, and business errors separately.

Idempotency

Webhook delivery and retryable API calls can produce duplicates. Use a stable Skedulo identifier, event identifier, or composite key such as Job ID and event timestamp.

Schema and tenant variation

Object availability and field names can vary by product configuration, enabled modules, and tenant. Version-control GraphQL queries and treat schema changes as deployment-impacting changes.

Scheduling data quality

Normalize timestamps carefully, preserve relevant source time zones, and validate relationships between Jobs, Resources, Allocations, Locations, and Territories.

Testing and observability

Test representative GraphQL responses, partial data, authorization failures, duplicate notifications, and pagination boundaries. Log correlation IDs and source identifiers without placing sensitive workforce or customer data in general logs.

Why use Martini instead of scripts or point-to-point integrations?

Reusable orchestration

Martini separates Skedulo access from downstream business processes so the same GraphQL and event-handling assets can support CRM, service, ERP, reporting, and notification use cases.

Controlled transformation

Workflows provide explicit mapping, normalization, validation, enrichment, and business-rule stages for tenant-specific Jobs, Resources, Allocations, and scheduling data.

Reliable operations

Instead of maintaining isolated scripts, teams can implement pagination, checkpoints, idempotency, retries, error paths, and monitoring as part of a managed integration workflow.

API-led design

Martini can consume Skedulo GraphQL operations and expose controlled APIs that hide implementation details from calling systems, allowing enterprise applications to interact through stable orchestration contracts.

Adaptable implementation

When Skedulo event coverage, schemas, or permissions differ by tenant, Martini workflows can accommodate conditional routing and custom transformation logic without assuming an unverified connector or REST surface.

Frequently asked questions

How can Skedulo be integrated with enterprise systems?

Skedulo can be integrated primarily through its GraphQL API, using queries and mutations for Jobs, Resources, Users, Locations, Allocations, and related scheduling data. Selected webhook-style notifications can support event-driven workflows, while token-based authentication controls access. A general equivalent REST API, bulk API, file API, and direct database access were not confirmed.

Can Martini integrate with Skedulo?

Yes. Martini can consume Skedulo’s GraphQL API from workflows, submit queries and mutations, map workforce data, expose APIs for orchestration, and receive supported Skedulo webhook-style notifications. The implementation should validate the tenant’s schema, permissions, and event coverage.

Do I need a connector to integrate Skedulo with Martini?

No. A dedicated Skedulo connector is not required. Martini can integrate with Skedulo using its confirmed GraphQL API, supported webhook-style notifications, token-based authentication, and standard API orchestration capabilities.

Is there any extra Lonti cost to integrate Skedulo with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Skedulo. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Skedulo, cloud infrastructure, or other third-party systems based on subscription, API usage, and deployment model.

Which Skedulo integration method should be used?

Use the Skedulo GraphQL API as the primary integration method for querying and mutating Jobs, Resources, Users, Locations, and Allocations. Use webhook-style notifications for selected supported events after confirming coverage for the specific tenant and object. Do not assume equivalent REST or SOAP APIs.

Can Martini receive Skedulo webhook events?

Yes, where the Skedulo tenant and event type support webhook-style notifications. Coverage should be validated for the specific Job, Resource, Allocation, or other event. Martini can receive the notification through an exposed API, validate it, apply idempotency controls, and start a workflow.

How should large Skedulo datasets be synchronized?

Use paginated GraphQL queries, incremental filters or tenant-supported change markers, bounded workflow batches, and durable checkpoints. A general-purpose Skedulo bulk export API was not confirmed, so integrations should not depend on a single unbounded request.

How does Martini handle Skedulo data mapping, errors, and duplicate events?

Martini can map GraphQL responses into canonical and downstream models, normalize scheduling timestamps, apply validation and business rules, and preserve Skedulo identifiers for correlation. Workflows can separate authentication, transport, GraphQL validation, business-rule, and throttling failures, retry transient errors, and use stable IDs or event keys to prevent duplicate processing.