Ellipse Gradient for Header

Microsoft To Do Integration Guide

Connect Microsoft To Do task lists and tasks with enterprise applications through Microsoft Graph REST APIs and Microsoft Entra ID OAuth 2.0 authentication.

Microsoft To Do integration options at a glance

Microsoft To Do is exposed through Microsoft Graph REST APIs, allowing authorized applications to manage todoTaskList, todoTask, checklistItem, and linkedResource objects. OAuth 2.0 access tokens issued by Microsoft Entra ID support delegated user access and, where available for the selected endpoints, application access. Microsoft Graph JSON batching can group requests, while change notifications may be usable for selected resources after validating exact To Do coverage. Where notifications or delta capabilities are insufficient, Martini can run scheduled workflows that paginate through @odata.nextLink, compare persisted state, and reconcile changes. Martini can also expose a controlled REST API for internal applications that need standardized task operations.

Integration pointSupported by Microsoft To Do?Common use casesHow Martini supports it
Microsoft Graph REST APIsYesList and manage todoTaskList objects, create and update todoTask objects, and manage checklist items and linked resources.Martini can consume the REST endpoints from workflows, construct authenticated requests, map JSON payloads, and orchestrate downstream writes.
OAuth 2.0 and Microsoft Entra IDYesAuthenticate delegated user access and, where supported by the endpoint, application or service-to-service access.Martini can use secured environment configuration and secrets for tenant values, client credentials, tokens, and endpoint authentication.
Webhooks and change notificationsLimitedReceive notifications for selected Microsoft Graph resources where the exact To Do resource and event type are supported.Martini can receive webhook-style notifications, but the subscription and resource coverage must be verified; scheduled polling is the fallback.
JSON batchingLimitedGroup multiple Microsoft Graph requests when synchronizing several lists or tasks, reducing network overhead without providing a To Do-specific bulk API.Martini can construct batch requests and process individual responses, including partial failures and throttling outcomes.
Pagination and incremental synchronizationYesRead collections across multiple pages using @odata.nextLink and reconcile task state when notifications or delta support is insufficient.Martini workflows can persist checkpoints, task identifiers, hashes, and synchronization outcomes for scheduled reconciliation.
Linked resourcesLimitedAssociate a task with a URL or related item in another Microsoft application, such as SharePoint content or an originating business record.Martini can map source URLs and correlation identifiers into linkedResource fields without treating them as file content.
File and attachment APIsLimitedTo Do supports linked resources, but no general To Do file-upload or attachment API was confirmed; files should remain in services such as SharePoint or OneDrive.Martini can call the relevant source-service API separately and place a resulting link in the To Do task where appropriate.
SDKsYesMicrosoft Graph SDKs are available, although direct REST calls remain suitable when explicit request, mapping, and retry control is required.Martini can consume the underlying REST API directly and encapsulate reusable request and transformation logic in workflows and services.

How Microsoft To Do exposes data and business events

Microsoft Graph REST APIs

Microsoft To Do task lists, tasks, checklist items, and linked resources are managed through Microsoft Graph REST endpoints. Typical operations include listing collections and creating, reading, updating, or deleting supported objects.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with Microsoft Entra ID, calls the appropriate Graph endpoint, follows pagination, maps the JSON response, applies business rules, and writes the result to the target system or returns a controlled API response.

Implementation sequence

Obtain an OAuth 2.0 access token with the required Graph permissions
Call the appropriate Microsoft Graph To Do endpoint
Follow @odata.nextLink until the collection is complete
Map the response into the canonical task model
Apply status, date, recurrence, and ownership rules
Write the result and persist identifiers and checkpoints

Change notifications

Microsoft Graph change notifications cover selected resources, but exact todoTask and todoTaskList support must be verified for the required event types, API version, and tenant.

Martini implementation pattern

Martini implementation pattern: receive a notification only after validating the supported subscription model, then retrieve the current resource from Microsoft Graph rather than relying solely on notification content. If coverage is insufficient, replace or supplement the trigger with scheduled reconciliation.

Implementation sequence

Verify To Do resource and event coverage for the tenant
Receive and validate the change notification
Retrieve the current task or list from Microsoft Graph
Map the current state and compare the synchronization key
Apply the downstream update or deletion rule
Record the notification and processing outcome

JSON batching

Microsoft Graph JSON batching groups multiple requests in one HTTP request. It is useful for reducing network overhead but is not a dedicated To Do bulk import or bulk update API.

Martini implementation pattern

Martini implementation pattern: assemble bounded batches of independent Graph operations, submit them through a workflow, inspect each individual response, and retry only safe transient failures while preserving correlation between subrequests and results.

Implementation sequence

Select independent task or list operations for a bounded batch
Build the Microsoft Graph JSON batch request
Submit the batch with the authorized access token
Process each individual response
Retry eligible transient failures with backoff
Persist successful and failed operation results

Scheduled synchronization

When change notifications or resource-specific incremental mechanisms are unavailable or incomplete, scheduled polling can reconcile Microsoft To Do state with another system.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow that reads task lists and tasks page by page, compares timestamps or hashes with persisted state, handles additions, updates, completions, and deletions, then stores a last-successful checkpoint.

Implementation sequence

Start the workflow on a defined schedule
Load the previous checkpoint and correlation state
Retrieve task lists and tasks with controlled pagination
Compare identifiers, timestamps, and relevant field hashes
Apply creates, updates, completions, and deletion rules
Store the checkpoint only after successful processing

Common Microsoft To Do integration patterns

Pattern 1: Create follow-up tasks from operational records

When to use this pattern

Use this pattern when a case, opportunity, incident, approval, or other business record should create a personal follow-up task in a designated Microsoft To Do list.

Integration direction
Salesforce
Martini
Microsoft To Do
Example Mapping
Microsoft To Do FieldCanonical FieldTarget Field
Case or opportunity identifiersourceRecordIdlinkedResource
TitletaskSubjectsubject
Target datedueDateTimedueDateTime
Urgencypriorityimportance
Martini implementation pattern

Martini receives or retrieves an eligible source record, validates ownership and required dates, maps its fields into a todoTask, and calls Microsoft Graph. The workflow stores the returned task ID with the source identifier, checks for an existing correlation before creation, and retries only safe transient failures.

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

Pattern 2: Synchronize Microsoft To Do tasks on a schedule

When to use this pattern

Use this pattern when a downstream project, service, or CRM system needs a periodic view of task lists, task status, due dates, or completion changes.

Integration direction
Microsoft To Do
Martini
ServiceNow
Example Mapping
Microsoft To Do FieldCanonical FieldTarget Field
todoTask.idexternalTaskIdu_external_task_id
todoTask.subjecttaskTitleshort_description
todoTask.statustaskStatusstate
todoTask.lastModifiedDateTimemodifiedAtsys_updated_on
Martini implementation pattern

A scheduled Martini workflow reads task lists and tasks, follows @odata.nextLink, compares persisted identifiers or hashes, and applies create, update, completion, and deletion rules to the target. It records checkpoints only after successful processing and isolates partial failures for retry.

Martini capabilities used
  • scheduler triggers
  • workflows
  • pagination handling
  • data mapping
  • state management
  • error handling

Pattern 3: Return completed tasks to the originating system

When to use this pattern

Use this pattern when staff complete Microsoft To Do tasks and the source case, onboarding process, or operational record must advance automatically.

Integration direction
Microsoft To Do
Martini
Salesforce
Example Mapping
Microsoft To Do FieldCanonical FieldTarget Field
todoTask.statuscompletionStateStatus
todoTask.idexternalTaskIdToDo_Task_ID
completedDateTimecompletedAtCompletedDateTime
linkedResourcesourceRecordUrlSource_Record_URL
Martini implementation pattern

Martini retrieves changed or completed tasks through verified notifications or scheduled polling, resolves the source record using a stored ID or controlled correlation value, and updates the target only when the completion transition is valid. Missing correlations are quarantined for review rather than creating unintended records.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • correlation management
  • business rules
  • conditional routing
  • monitoring

Pattern 4: Expose a centralized task API

When to use this pattern

Use this pattern when multiple internal applications need to create or update Microsoft To Do tasks without each application implementing Microsoft Graph authentication and mapping logic.

Integration direction
Internal applications
Martini
Microsoft To Do
Example Mapping
Microsoft To Do FieldCanonical FieldTarget Field
applicationRecordIdsourceRecordIdlinkedResource
titletaskSubjectsubject
requestedDueDatedueDateTimedueDateTime
recurrenceRulerecurrencepatternedRecurrence
Martini implementation pattern

Martini exposes a secured REST API, validates the caller payload, selects the target user and todoTaskList, applies organization-specific rules, and invokes Microsoft Graph. The workflow returns a controlled result and correlation ID while keeping Graph credentials and vendor-specific details behind the API.

Martini capabilities used
  • API exposure
  • authentication and authorization
  • workflows
  • validation
  • data transformation
  • error handling

Applications commonly integrated with Microsoft To Do

Microsoft To Do can be connected to Microsoft 365 applications and enterprise systems when personal follow-up work, operational tasks, or completion status must be coordinated. Martini can mediate these flows through Microsoft Graph and the relevant application APIs.

Application Scenario Direction Martini Pattern
Microsoft Outlook Convert flagged email and follow-up work into Microsoft To Do tasks while allowing completion status to participate in operational workflows. Microsoft Outlook → Martini → Microsoft To Do Receive or retrieve Outlook-related work through the applicable Microsoft API, map message identifiers and links into linkedResource and task fields, then create or update a todoTask through Microsoft Graph. Persist the task ID and apply duplicate checks.
Microsoft Teams Create personal action items from conversations, meetings, or Teams-facing work and coordinate task completion with downstream processes. Microsoft Teams → Martini → Microsoft To Do Use the relevant Teams or Microsoft Graph resource as the source, transform conversation or meeting context into subject, body, dueDateTime, and linkedResource values, and route the result to the user's selected todoTaskList. Validate the exact Teams resource behavior for the tenant.
Microsoft Planner Coordinate personal follow-up work related to Planner assignments and team planning. Microsoft Planner → Martini → Microsoft To Do Retrieve supported Planner data through the applicable Microsoft API, map assignment and plan context into Microsoft To Do fields, and maintain correlation identifiers for status reconciliation. Confirm the required Planner and To Do resource permissions before deployment.
Microsoft Power Automate Use Microsoft To Do task creation or completion as part of broader Microsoft 365 automation flows. Microsoft Power Automate → Martini → Microsoft To Do Expose or consume a controlled Martini REST API around task operations, validate incoming payloads, apply organization-specific routing and mapping rules, and call Microsoft Graph with secured OAuth credentials.
Salesforce Create follow-up tasks for leads, contacts, opportunities, or cases and return completion information to Salesforce. Salesforce → Martini → Microsoft To Do Consume Salesforce events or API data, map the source identifier, title, urgency, target date, details, and URL into a todoTask, then persist the Microsoft To Do task ID. A scheduled workflow can reconcile completion changes back to Salesforce.
ServiceNow Create personal action items from incidents, requests, approvals, or other operational records. ServiceNow → Martini → Microsoft To Do Consume ServiceNow API data, apply task eligibility and assignment rules, create the corresponding todoTask through Microsoft Graph, and store a correlation key. Use retries for transient failures and optionally synchronize completion back to ServiceNow.
Jira Create personal follow-up tasks from issues, sprint work, or escalations. Jira → Martini → Microsoft To Do Retrieve eligible Jira issues, transform issue links and status into task fields and linkedResource values, and write to the appropriate Microsoft To Do list. Reconciliation workflows can update Jira when a correlated task is completed.
SharePoint Create tasks associated with documents, lists, or approval work while retaining links to SharePoint content. SharePoint → Martini → Microsoft To Do Use SharePoint content metadata and URLs as the source, create a todoTask with a linkedResource reference, and keep document content in SharePoint. Martini can synchronize task status without copying unsupported file content into To Do.

How to build a Microsoft To Do integration in Martini

Objective

Establish Microsoft Graph access with an Entra ID application registration and the least-privilege delegated or application permissions required by the selected To Do endpoints.

Instructions in Martini

  • Configure the Graph OAuth 2.0 authentication model
  • Store tenant values, client secrets, and tokens in Martini secrets or secure environment configuration
  • Confirm consent and user-context requirements for /me or user-specific paths

Objective

Select an event-driven or scheduled entry point based on verified Microsoft Graph change-notification coverage for the required To Do resource.

Instructions in Martini

  • Use a webhook-style trigger only after confirming exact resource support
  • Use a scheduler when notification coverage is unavailable or incomplete
  • Define the synchronization interval and ownership model

Objective

Call Microsoft Graph REST endpoints to retrieve task lists and tasks, handling pagination and current-resource retrieval consistently.

Instructions in Martini

  • Call the appropriate list, task, checklist, or linked-resource endpoint
  • Follow @odata.nextLink until all required pages are processed
  • Capture request identifiers and relevant timestamps for support

Objective

Coordinate source retrieval, Microsoft Graph calls, transformations, routing, persistence, and downstream updates in a maintainable Martini workflow.

Instructions in Martini

  • Separate source acquisition from target writes
  • Use conditional branches for creates, updates, completions, and deletions
  • Persist correlation IDs and synchronization checkpoints

Objective

Convert Microsoft Graph JSON and downstream payloads into a canonical task model while preserving date, user, recurrence, and linked-resource semantics.

Instructions in Martini

  • Map subject, status, dueDateTime, importance, body, and completion fields
  • Normalize time zones and all-day dates carefully
  • Translate supported patternedRecurrence structures explicitly

Objective

Enforce task ownership, list routing, duplicate prevention, permission boundaries, and conflict-resolution policies before writing data.

Instructions in Martini

  • Validate required identifiers and target lists
  • Check synchronization state before creating a task
  • Quarantine unsupported recurrence or ambiguous correlation cases

Common Microsoft To Do data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
todoTaskListRepresents a user's default or custom task list and provides the container for todoTask objects.Microsoft Outlook, Microsoft Teams, Salesforce, ServiceNow, JiraMartini lists, creates, updates, or deletes task lists through Microsoft Graph and stores list identifiers for routing and synchronization.
todoTaskRepresents an individual task with subject, status, due date, importance, body, recurrence, and completion information.Salesforce, ServiceNow, Jira, SharePoint, Microsoft PlannerMartini maps source work into todoTask fields, applies validation and business rules, persists correlation IDs, and handles retries and duplicate prevention.
checklistItemRepresents a checklist entry associated with a todoTask.ServiceNow, Salesforce, Microsoft TeamsMartini can transform checklist requirements into or from downstream task details where the required Graph operations and permissions are available.
linkedResourceReferences related content or an originating item, such as a SharePoint URL or source-system record.SharePoint, Microsoft Outlook, Salesforce, ServiceNow, JiraMartini maps stable URLs and source identifiers into linked resources and keeps the authoritative content in the originating system.
userIdentifies the Microsoft Graph user whose lists and tasks are being accessed, especially for user-specific paths.Microsoft Entra ID, Microsoft Teams, Microsoft Outlook, enterprise identity systemsMartini applies the selected delegated or application access model and routes requests according to the authorized user context.
patternedRecurrenceDefines the pattern and range for recurring todoTask instances.Salesforce, ServiceNow, Jira, Microsoft PlannerMartini translates supported recurrence rules, validates unsupported patterns, and avoids silent changes caused by incompatible date or recurrence models.

Authentication and security considerations

Microsoft Entra ID and OAuth 2.0

Microsoft To Do access is provided through Microsoft Graph with OAuth 2.0 bearer tokens issued by Microsoft Entra ID. Delegated permissions support signed-in user access, while application permissions may be available for supported background scenarios.

Permissions and consent

Common permissions include Tasks.Read, Tasks.ReadWrite, Tasks.Read.Shared, and Tasks.ReadWrite.Shared. The selected endpoint, user context, tenant configuration, and application model determine the required permissions and consent.

Secret protection

Store client secrets, tenant values, refresh or access-token configuration, and related sensitive settings in Martini secrets or secure environment configuration rather than embedding them in workflows.

Operational considerations for Microsoft To Do integrations

Pagination and throttling

Follow @odata.nextLink for collection responses. Handle HTTP 429 responses, honor Retry-After when provided, and use bounded exponential backoff for eligible transient failures. JSON batching does not remove individual request limits.

Idempotency and correlation

Persist source identifiers and Microsoft To Do task IDs. A request can succeed before a client receives its response, so duplicate prevention and reconciliation are required before creating a new todoTask.

Dates, recurrence, and deletion

Normalize time zones and all-day due dates carefully. Validate patternedRecurrence translations, define deletion behavior, and use periodic reconciliation when notifications or delta capabilities do not cover the required resources.

Testing and schema changes

Test delegated and application access separately, validate permissions for the target tenant, avoid undocumented fields, and isolate mappings so Microsoft Graph resource or permission changes can be managed without rewriting the whole workflow.

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

Orchestration instead of isolated scripts

Martini provides a workflow layer for authentication, Microsoft Graph calls, pagination, transformation, business rules, target updates, and operational error handling. This keeps vendor-specific logic separate from downstream application behavior.

Reusable integration assets

Teams can expose a controlled REST API, reuse mappings and validation logic, and support both real-time requests and scheduled reconciliation without distributing Microsoft Graph credentials across applications.

Operational reliability

Centralized checkpoints, correlation identifiers, retries, logging, and monitoring make task synchronization more observable and maintainable than independent scripts or tightly coupled point-to-point integrations.

Frequently asked questions

How can Microsoft To Do be integrated with enterprise systems?

Microsoft To Do is integrated through Microsoft Graph REST APIs using OAuth 2.0 access tokens issued by Microsoft Entra ID. Integrations can manage todoTaskList and todoTask objects, use JSON batching, and use verified change notifications or scheduled polling for synchronization.

Can Martini integrate with Microsoft To Do?

Yes. Martini can consume Microsoft Graph REST APIs, authenticate with Microsoft Entra ID OAuth 2.0, map To Do JSON data, orchestrate task workflows, and expose a controlled API for internal applications. No native Martini Microsoft To Do connector is documented in the supplied materials.

Do I need a connector to integrate Microsoft To Do with Martini?

No. A dedicated Microsoft To Do connector is not required. Martini can use Microsoft To Do's confirmed native integration mechanisms: Microsoft Graph REST APIs, OAuth 2.0 authentication, verified change notifications where available, and scheduled synchronization.

Is there any extra Lonti cost to integrate Microsoft To Do with Martini?

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

Which Microsoft To Do integration methods should be used?

Microsoft Graph REST APIs are the primary and recommended method. OAuth 2.0 through Microsoft Entra ID provides authentication, while JSON batching can group requests. Microsoft To Do does not expose a confirmed GraphQL or SOAP API.

Are Microsoft To Do webhooks or events available?

Microsoft Graph supports change notifications for selected resources, but To Do-specific coverage must be verified for the exact resource, event type, API version, and tenant. If coverage is insufficient, Martini can use a scheduled workflow to poll and reconcile task state.

How does synchronization between Microsoft To Do and another application work?

Martini can read task lists and tasks, follow @odata.nextLink pagination, map fields into a canonical model, and write changes to another system. A robust design persists task identifiers, source identifiers, hashes or timestamps, checkpoints, ownership rules, conflict behavior, and deletion handling.

How are errors, retries, and duplicate tasks handled?

Martini can distinguish authentication, permission, validation, missing-resource, throttling, and transient server errors. Workflows should honor Retry-After for HTTP 429 responses, use bounded backoff for safe transient failures, and persist correlation IDs so a timeout does not create duplicate todoTask objects.