---
title: "Hire Microsoft Dynamics 365 Integration Engineers"
canonical_url: https://msdynamicsguys.com/hire/dynamics-365-integration-engineers/
description: "Add a Microsoft Dynamics 365 integration engineer for APIs, middleware, retries, monitoring and reconciliation under your lead."
publisher: "MS Dynamics Guys"
last_modified: 2026-10-14
---

# Hire Microsoft Dynamics 365 integration engineers

> **In short:** MS Dynamics Guys provides integration engineers who join your team to build and run the connections between Microsoft Dynamics 365 and your other systems. They work with product APIs (application programming interfaces), service identities, duplicate-safe retries and monitoring. Where a standard connector or a direct call is not enough, they add Azure services. Before the first interface goes live, we agree in writing who receives alerts, who replays failed messages and who signs off reconciliation. Your lead sets the priorities.

**At a glance**

- **Builds and runs:** Interfaces on product APIs and Azure services, with service identities, retries, alerts, replay and reconciliation checks
- **Assessment:** Map the records one interface moves, then plan how its failures are found, retried, replayed and reconciled
- **Direction:** Your lead assigns the interfaces and approves each release; your administrators grant and revoke every identity
- **Failed syncs:** Alert recipients, replay approval and reconciliation sign-off are agreed in writing before go-live
- **Terms:** Hours, on-call participation, allocation, notice, minimum term, replacement and pricing basis: agreed in writing per engagement

[Describe an integration gap](https://msdynamicsguys.com/contact/#intent=hiring&service=H19&role=integration) · [See integration services](https://msdynamicsguys.com/services/dynamics-365-integration/)

## When an integration engineer from MS Dynamics Guys fits your team

Some teams call this role an integration developer. The work is the same: build the connections between Microsoft Dynamics 365 and your other systems, then keep them working in production. The role suits a team that runs its own integration program, with a lead who sets priorities and an owner for each system. To compare it with other roles, use the [Microsoft Dynamics 365 role chooser](https://msdynamicsguys.com/hire/).

### Team situations that call for this role

- **Users find failures before alerts do.** A missing order or a doubled customer reaches your service desk as a complaint. Only then does someone open the interface log.
- **Connector exceptions need manual fixes.** A standard connector handles the usual case. Every week, someone on your team corrects returns, partial shipments or rejected lines by hand.
- **One person knows the code.** The functions, flows and mappings behind your interfaces depend on one colleague. Nobody else knows how to replay a failed message.
- **Month-end loads hit throttling.** Large period-end loads get 429 Too Many Requests responses, which tell the caller to slow down. The retries then stop halfway or create duplicate records.

### When a different role or a project suits you better

- You want MS Dynamics Guys to deliver an integration and answer for its acceptance. Choose an [integration project](https://msdynamicsguys.com/services/dynamics-365-integration/) instead of a hire.
- Most of the work is Power Automate cloud flows: their owners, connections and approvals. A [Power Automate developer](https://msdynamicsguys.com/hire/power-automate-developers/) fits better.
- The work is setting up an integration that Microsoft already provides, with no custom code or middleware. An example is the standard coupling between Microsoft Dynamics 365 Sales and Business Central. That is configuration work for a [technical consultant](https://msdynamicsguys.com/hire/dynamics-365-consultants/).
- Nobody has decided which system owns each record, or how your interfaces fit together. Start with a [solution architect](https://msdynamicsguys.com/hire/dynamics-365-solution-architects/).
- The data moves once, at go-live, with trial loads and a cutover. That is work for a [data migration engineer](https://msdynamicsguys.com/hire/dynamics-365-data-migration-engineers/). Interfaces that must point at the new system on cutover day still need an integration engineer.
- The gap is code inside one product, such as a plug-in for your customer relationship management (CRM) apps or a Business Central extension. A [CRM developer](https://msdynamicsguys.com/hire/dynamics-365-crm-developers/) or a [Business Central developer](https://msdynamicsguys.com/hire/business-central-developers/) fits better.
- The interface needs a new or changed data entity in Microsoft Dynamics 365 Finance or Supply Chain Management. That is development in X++, the programming language of finance and operations apps, for a [finance and operations developer](https://msdynamicsguys.com/hire/dynamics-365-finance-operations-developers/).
- Nobody on your side can receive alerts or approve a replay. Name those people before an engineer starts.

## Work an integration engineer can own

Your lead assigns the interfaces. For each one, the engineer delivers the items below, and your people keep the decisions in the last column.

**Integration engineer work: what the engineer delivers and what your team keeps**

| Area | What the engineer delivers | What your team keeps |
|---|---|---|
| Flow specification | One page per interface: the records it moves, matching keys, direction, timing, error handling, alert recipient and reconciliation check | Which system owns each record, and which fields each side may change |
| Endpoints, functions and queue handlers | Code and configuration in your repository, built and tested outside production and reviewed before each release | Design approval, code review rules and the release decision |
| Dataverse identity | One application user per integration in Dataverse, the data platform under Microsoft Dynamics 365 Sales and Customer Service. Each user is tied to one Microsoft Entra app registration or managed identity, with a security role built for that interface alone. | Creating the app registration and the application user, and rotating any credentials |
| Business Central identity | A Microsoft Entra application set up on the Microsoft Entra applications page, with only the permission sets the interface needs. Business Central does not allow the SUPER permission set for applications. | Granting consent and permissions, and rotating credentials |
| Finance and Supply Chain Management identity | A Microsoft Entra application added on the Microsoft Entra applications page and mapped to a dedicated service account with only the roles the interface needs | Registering the application, creating the service account and rotating credentials |
| Azure identity | Managed identities for the Azure resources that run the integration, so their code gets Microsoft Entra tokens without stored passwords or keys | Role assignments in your Azure subscription |
| Duplicate-safe writes | Writes keyed on an identifier that both systems share, so a message that arrives twice updates the same record instead of creating a copy | Agreement on each matching key with the owner of each system |
| Replay | A tested way to resend failed messages once the cause is fixed. This covers dead-lettered messages: those set aside in a separate queue after repeated failures. | Approval for replays that post financial records, such as invoices or payments |
| Alerts | Alert rules for failed runs, dead-lettered messages and rising error rates, each sent to a named recipient | Who receives alerts during and outside working hours |
| Reconciliation | Scheduled count and total checks between the systems, with a list of differences | Sign-off on each difference, and corrections to source data |
| Runbook | A runbook for each interface: written steps for reading its alerts, finding a failed message, replaying it and escalating | Where the runbook lives, and who keeps it current after handover |

Your team also owns the Azure subscription and pays its costs. The engineer starts with what the products already offer: standard APIs, Microsoft connectors and webhooks. Azure services come in only when volume, ordering or replay needs go beyond them, and the flow specification records the reason.

## Who owns failed syncs when an integration engineer from MS Dynamics Guys joins your team?

Your team owns the decisions, and the engineer does the work. With read access to logs, telemetry and failed messages, the engineer handles alerts, diagnoses failures and replays messages inside your incident process. Your team keeps the on-call rotation, corrections to source data and approval for replays that post financial records. Alert rules, the replay procedure and the runbook stay in your repository, so these duties outlast the engagement.

We write this split down before the first interface goes live. The table shows the split that MS Dynamics Guys proposes; your signed agreement sets the final one.

**Failed-sync duties during the engagement and after handover**

| Step | MS Dynamics Guys engineer | Your team | After handover |
|---|---|---|---|
| Detect | Writes the alert rules | Receives the alerts | The rules stay in your repository |
| Fix | Corrects code or mappings, through review | Corrects source data | The fix history stays in your backlog |
| Replay | Resends dead-lettered messages | Approves replays that post financial records | A written replay procedure |
| Reconcile | Builds count and total checks | Signs off differences | A scheduled check |
| Access | Uses named identities with only the access each interface needs | Grants, rotates and revokes access | The engineer's access is removed at exit |

Whether the engineer also joins your on-call rotation, and for which hours, is agreed per engagement. The questions at the end of this page list what to decide before go-live.

## Product behavior the engineer designs around

Each product signs callers in, slows them down and reports failures in its own way. The engineer builds retries, alerts and replays around the documented behavior. Microsoft can change these limits, so they are worth checking again before each release.

**Dataverse** stores the data of Microsoft Dynamics 365 Sales and Customer Service. Application users get the same service protection limits as people. Above those limits, the Web API answers 429 Too Many Requests with a Retry-After header that gives the seconds to wait. An upsert finds a record by an alternate key, such as a column that holds the source system's customer number. It updates the record if it exists and creates it if not, so a resent message changes the same record. Dataverse can also post events to Azure Service Bus, where they wait in a queue until a handler reads them.

**Business Central online.** Integrations call API v2.0 or custom API pages written in AL, the programming language of Business Central. A caller that exceeds its rate, connection or queue limit gets 429 Too Many Requests. These limits count per user and apply to application identities in the same way, and Microsoft suggests spreading a heavy load across several identities. A request that waits in the queue for 8 minutes gets 503 Service Temporarily Unavailable with a Retry-After header. Business Central can also send telemetry to an Application Insights resource in your Azure subscription. Its web service trace records each call's endpoint, status code and any failure reason. Webhook subscriptions expire after three days unless renewed. The Business Central example below shows how the engineer keeps them working.

**Power Automate** cloud flows suit event-driven work at moderate volume. By default, their actions retry up to 12 times on the Medium and High performance profiles. Every write in a flow must therefore be safe to repeat. Endpoint addresses belong in environment variables, and secret values can come from Azure Key Vault. When volume, ordering or replay needs outgrow a flow, the engineer proposes a queue or a function and records why.

**Microsoft Dynamics 365 Finance and Supply Chain Management.** Integrations read and write data entities. Calls through the Open Data Protocol (OData) run at once and return any error to the caller. The batch data API, which covers recurring integrations and data packages, only schedules a batch job. The caller must then poll for the result and handle the errors. Microsoft's rule of thumb is to use the batch data API above a few hundred thousand records.

**Azure services.** A Service Bus message that still fails after the maximum number of delivery attempts, 10 by default, moves to a dead-letter queue. It stays there until someone removes it. Duplicate detection drops a resent message with a known message ID. It works only within its history window, 10 minutes by default, and not in the Basic tier. So it can back up a matching key, but not replace it. Logic Apps resend a request that fails with 408, 429 or a 500-range code, up to four times by default for most operations. The design gives each of these behaviors a matching key, an alert or a replay step.

## How MS Dynamics Guys assesses an integration engineer

The exercise covers one whole interface. The candidate maps the records it moves, then plans how its failures are found, retried, replayed and reconciled. A reviewer scores the plan against the skills below.

**Integration engineer assessment: skill, review method and artifact**

| Skill | How we review it | Artifact the review produces |
|---|---|---|
| Mapping | The candidate maps a sample payload to the target records and chooses a matching key for each record type | A mapping and key sheet |
| Identity | The candidate sets up unattended access for the interface and names who grants, rotates and revokes each credential | A grant and rotation table |
| Duplicates | We resend one message. The candidate shows why it updates the existing record instead of creating a copy, for example through a shared key or Service Bus duplicate detection. | The write design and the test that proves it |
| Throttling in Dataverse | The candidate explains how the client reacts to 429 Too Many Requests: it pauses for the seconds in the Retry-After header, then sends fewer requests | Retry and pacing rules for the interface |
| Throttling in Business Central | The candidate tells two responses apart: 429 for the rate, connection and queue limits, and 503 when a queued request times out after 8 minutes | Retry rules that back off, with fewer parallel calls |
| Batch jobs in Finance and Supply Chain Management | The candidate plans how the client polls an asynchronous import for its status and collects the errors of rejected records | A status and error-handling plan for the job |
| Recovery | We send a poison message, one that fails on every attempt. The candidate traces it to the dead-letter queue, the alert and the replay after the fix. | A failure catalog entry and a replay procedure |
| Reconciliation | The candidate designs a count and total check for a closed period and names who signs off each difference | A reconciliation query outline with its sign-off owner |

The written result also lists the gaps your interview should probe.

Buyers who compare several providers can give each candidate the interface task in our [hiring scorecard](https://msdynamicsguys.com/resources/dynamics-365-hiring-scorecard/).

## Example first work package: make one customer sync recoverable

> **Illustrative example: not a client case and not a delivery-time promise**
>
> The pace of a package like this depends on how quickly access, reviews and releases happen on your side.
>
> **The situation.** Customer records from your enterprise resource planning (ERP) system update accounts in Dataverse through an Azure Service Bus queue. Some accounts appear twice, others do not arrive at all, and nobody receives an alert. **The task:** make this one sync recoverable without changing which system owns the customer record.
>
> **What the engineer delivers:**
>
> - A mapping sheet: each ERP field, its Dataverse column and the alternate key that holds the ERP customer number.
> - A failure catalog: each known failure, how it shows, its cause and whether code or data must change.
> - A change to the queue handler that writes accounts through an upsert on the alternate key, not a create. It arrives as a pull request to your repository.
> - Dead-letter handling: a message that keeps failing moves to the dead-letter queue with a reason, and the handler stops retrying it.
> - Alerts that reach the named owner when the dead-letter queue holds messages or the error rate rises.
> - A reconciliation query that compares account counts per period in both systems.
> - A runbook: how to read an alert, find the message, fix or escalate the cause, and replay.
>
> **Acceptance criteria:**
>
> - A message sent twice leaves one account, updated, and no copy.
> - A forced 429 Too Many Requests response ends in success after the wait that the Retry-After header asks for.
> - A poison message reaches the dead-letter queue, alerts the named owner and replays successfully after the fix.
> - Account counts match in both systems for a closed period.
> - Your on-call person replays a test message using only the runbook.

## Example first work package in Business Central: keep webhook changes arriving

> **Illustrative example: not a client case and not a delivery-time promise**
>
> Your online store subscribes to Business Central webhooks for item and sales order changes. Now and then, changes stop arriving, and nobody notices for days.
>
> **What the engineer delivers:**
>
> - A scheduled job that renews each subscription before its three-day expiry. Renewal repeats the validation handshake, and the job alerts the named owner when a renewal fails.
> - A subscriber endpoint that answers its own failures with 408, 429 or a 500-range code. Business Central then retries for up to 36 hours. Any other error code would delete the subscription.
> - Handling for `collection` notifications. Business Central waits 30 seconds before it notifies. When more than 1,000 records change in that time, it sends one such notification instead of one per record. The handler reads the changed records through the filter that the notification carries.
> - A scheduled check that compares recent changes in Business Central with the changes that arrived. It also catches changes that are not notified at once, such as those a partner's delegated administrator makes.
>
> **Acceptance criteria:**
>
> - Every subscription renews in a sandbox without manual steps.
> - A forced subscriber failure leads to retries, not a deleted subscription.
> - A change to more than 1,000 records within 30 seconds arrives as one `collection` notification and is processed in full.
> - The scheduled check reports any record that no notification delivered.

## One engineer, part of a team or an owned integration

The ways to add integration capacity differ in who plans the daily work and who answers when a sync fails.

**Ways to engage an integration engineer, and who answers for failed syncs**

| Option | Who directs the work | Who answers for failed syncs | More about the model |
|---|---|---|---|
| One engineer in your team | Your lead, through your backlog and review rules | Your team, under the duties agreed in writing; the engineer works the alerts and replays | [Staff augmentation](https://msdynamicsguys.com/services/dynamics-365-staff-augmentation/) |

Part of your backlog may turn into one defined integration. [Staff augmentation versus project delivery](https://msdynamicsguys.com/resources/dynamics-365-staff-augmentation-vs-project-delivery/) lists what to collect before you move it to a work package.

To buy a whole integration as a project, with MS Dynamics Guys answerable for the result, see [Microsoft Dynamics 365 integration services](https://msdynamicsguys.com/services/dynamics-365-integration/).

## How work with an integration engineer starts

Who answers alerts is agreed before the engineer gets access to your systems. Dates come only after your interview and the signed agreement, and no step has a fixed duration.

1. **Your role brief:** Name the systems on each side, the interfaces and their volumes, the failures you see today and who receives alerts now. Add your integration platform, your repository and the hours your team works.
2. **Fit review:** We check whether the gap needs an integration engineer, a product developer, an architect or a project. Before any introduction, we also tell you whether MS Dynamics Guys can staff the role.
3. **Assessed candidates:** Profiles reach you only for candidates who passed the interface exercise. Each comes with the candidate's mapping and key sheet, the replay procedure and the reviewer's notes.
4. **Your interview:** Repeat the mapping exercise on one of your own interfaces, with sensitive data removed. Your lead or architect decides who joins.
5. **Incident duties in writing:** The agreement names who receives alerts, who replays messages, who approves financial replays and who signs off reconciliation. It also states whether the engineer joins your on-call rotation, and for which hours.
6. **Read access, then an inventory:** Your administrators first grant read access to logs, telemetry and failed messages. The first task is an inventory of your interfaces, the identities they run as and the alerts that exist.
7. **First accepted change:** One small change, such as a new alert rule or a duplicate-safe write, is reviewed and accepted against criteria your lead wrote.

After that, [how we work](https://msdynamicsguys.com/how-we-work/) sets out how changes are reviewed, released and handed over.

The [contractor onboarding checklist](https://msdynamicsguys.com/resources/dynamics-365-contractor-onboarding-checklist/) lists the accounts, repository access and exit steps that any external specialist needs.

## Check an integration engineer against your own interfaces

Until we have approved cases, this page names no clients and quotes no reviews.

Three checks need no case study: the written result of the interface exercise, your interview and the first change your lead accepts or rejects. No exercise shows how a candidate works through a live incident. So in your interview, give the candidate the alert from the runbook entry below, and ask them to work through it aloud. [Our screening page](https://msdynamicsguys.com/how-we-work/technical-screening/) explains who reviews the interface exercise.

We wrote the runbook entry below as an original demonstration for this page. No client system supplied it, and it describes no candidate.

**Demonstration: a runbook entry for one dead-lettered customer message, written for this page**

| Runbook field | Entry |
|---|---|
| Alert | The dead-letter queue for customer updates holds one or more messages |
| First check | Read the dead-letter reason and the error description stored with each message |
| Data or code? | A missing country code in the source record is a data problem. A mapping error after a release is a code problem. |
| Fix | The customer data owner corrects the source record; the engineer does not edit customer data. A code problem gets a reviewed change, released through your pipeline. |
| Replay | Resend the message after the fix, for example with Service Bus Explorer in the Azure portal. Customer updates need no finance approval; invoice and payment messages do. |
| Confirm | The customer exists once in the target system, and the next reconciliation run shows no difference for it. A new cause goes into the failure catalog. |

In a real assessment, the candidate writes an entry like this for a failure we describe, then walks the reviewer through each step.

## Practical questions about hiring an integration engineer

### Do we need an integration engineer or a developer for one product?

Look at where the work sits. Code inside one product, such as a plug-in, an extension or a cloud flow, belongs to a developer for that product. The integration engineer owns the path between systems: identities, queues or middleware, retries, alerts, replay and reconciliation. Many teams need both roles. The developer builds the endpoint, and the engineer makes the interface recoverable.

### Our interfaces already run on an integration platform. Will the engineer move them to Azure?

No. Name your platform in the role brief, with the interfaces that run on it. Before any introduction, we tell you in writing whether we can staff the role for that platform. The engineer then works in your platform and your repository. Moving interfaces to another platform is a separate decision for your lead or architect. It is not part of the hire unless you ask for it.

### Will the engineer join our on-call rotation?

That is agreed per engagement, and this page states no on-call hours. Before go-live, decide three things: which alerts need action outside working hours, who receives them, and who may pause an interface or replay messages. If the engineer joins the rotation, the agreement names the hours. If not, your own on-call person replays messages from the runbook without the engineer.

### Who owns the Azure resources, secrets and code?

Your organization, under the written agreement. The Azure resources sit in your subscription, and you pay for them. Code, alert rules and runbooks live in your repository from the first commit. Your administrators create the identities and keep each secret in a vault you control, such as Azure Key Vault. The agreement sets ownership of code and documents before work starts.

### How do on-call duty and Azure usage affect what we pay?

The pricing basis is agreed in writing per engagement, and this page quotes no rates. For an engineer in your team, the basis is usually time. On-call duty adds to the hours you need covered, so decide it before you ask for a price. The number of products and platforms involved, and the length of the engagement, also move the cost. Azure usage, monitoring data and Microsoft licenses stay with you, billed through your own subscriptions and agreements.

### Can our team run the interfaces without the engineer?

Yes, and the handover is built for that. Each interface has a flow specification, a failure catalog and a runbook in your repository. Before the handover is accepted, your on-call person replays a message using only the runbook. Notice and replacement follow the written agreement. Before a planned exit, the engineer hands over open incidents, known failure patterns and pending changes. Your administrators then remove the engineer's identities and rotate every secret the engineer could read.

## Related roles, services and guides

- [Microsoft Dynamics 365 integration](https://msdynamicsguys.com/services/dynamics-365-integration/): Integration delivered as a project, with MS Dynamics Guys answerable for the result.
- [Business Central integration](https://msdynamicsguys.com/integrations/business-central/): Business Central integrations: standard APIs, connectors, webhooks and custom API pages.
- [Microsoft Dynamics 365 CRM developers](https://msdynamicsguys.com/hire/dynamics-365-crm-developers/): Plug-ins and custom APIs when the gap is code inside the CRM apps on Dataverse.
- [Business Central developers](https://msdynamicsguys.com/hire/business-central-developers/): Extensions and API pages when the gap is code inside Business Central.
- [Power Automate developers](https://msdynamicsguys.com/hire/power-automate-developers/): Cloud flows, their owners and their connections, when the work stays inside Power Automate.
- [Solution architects](https://msdynamicsguys.com/hire/dynamics-365-solution-architects/): Record ownership, integration boundaries and design decisions across a program.
- [Data migration engineers](https://msdynamicsguys.com/hire/dynamics-365-data-migration-engineers/): One-time data loads with mapping, trial runs, reconciliation and cutover.
- [Staff augmentation](https://msdynamicsguys.com/services/dynamics-365-staff-augmentation/): How a specialist joins a team that you manage, from onboarding to exit.
- [Technical screening](https://msdynamicsguys.com/how-we-work/technical-screening/): How candidates are tested before any introduction, and what a test cannot prove.
- [Staff augmentation vs project delivery](https://msdynamicsguys.com/resources/dynamics-365-staff-augmentation-vs-project-delivery/): Staff augmentation and project delivery compared by direction, risk and pricing basis.
- [Onboarding checklist](https://msdynamicsguys.com/resources/dynamics-365-contractor-onboarding-checklist/): Accounts, access and exit steps to prepare before any external specialist starts.

## Describe an integration gap

Tell us the systems on each side, the interfaces involved, what fails today and who receives alerts now. Add your integration platform, your time zone and the hours your team works. Our first reply proposes a role for the failures you describe, or asks what we still need to know.

[Describe an integration gap](https://msdynamicsguys.com/contact/#intent=hiring&service=H19&role=integration) · [See integration services](https://msdynamicsguys.com/services/dynamics-365-integration/)

## Product documentation referenced on this page

- [Manage Microsoft Dynamics 365 apps that run on Microsoft Dataverse](https://learn.microsoft.com/en-us/power-platform/admin/manage-apps) (checked 2026-10-04)
- [Manage application users in the Power Platform admin center](https://learn.microsoft.com/en-us/power-platform/admin/manage-application-users) (checked 2026-10-04)
- [Service protection API limits (Dataverse)](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/api-limits) (checked 2026-10-04)
- [Use Upsert to create or update a record in Dataverse](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/use-upsert-insert-update-record) (checked 2026-10-04)
- [Azure Service Bus integration for Dataverse](https://learn.microsoft.com/en-us/power-apps/developer/data-platform/azure-integration) (checked 2026-10-04)
- [API page type (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-api-pagetype) (checked 2026-10-04)
- [Using service-to-service authentication (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/automation-apis-using-s2s-authentication) (checked 2026-10-04)
- [Integrating Business Central with Microsoft Dynamics 365 Sales](https://learn.microsoft.com/en-us/dynamics365/business-central/admin-prepare-dynamics-365-for-sales-for-integration) (checked 2026-10-04)
- [Operational limits for Business Central online](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/operational-limits-online) (checked 2026-10-04)
- [Web service request trace (Business Central telemetry)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/telemetry-webservices-trace) (checked 2026-10-04)
- [Monitoring and analyzing telemetry (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/telemetry-overview) (checked 2026-10-04)
- [Working with webhooks (Business Central)](https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/api-reference/v2.0/dynamics-subscriptions) (checked 2026-10-04)
- [Limits of automated, scheduled and instant flows (Power Automate)](https://learn.microsoft.com/en-us/power-automate/limits-and-config) (checked 2026-10-04)
- [Use environment variables in Power Platform solutions](https://learn.microsoft.com/en-us/power-apps/maker/data-platform/environmentvariables) (checked 2026-10-04)
- [Data entities overview (finance and operations apps)](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/data-entities) (checked 2026-10-04)
- [Integration between finance and operations apps and third-party services](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/integration-overview) (checked 2026-10-04)
- [Service endpoints overview (finance and operations apps)](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/services-home-page) (checked 2026-10-04)
- [X++ language reference](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-ref/xpp-language-reference) (checked 2026-10-04)
- [Service Bus dead-letter queues](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dead-letter-queues) (checked 2026-10-04)
- [Azure Service Bus duplicate message detection](https://learn.microsoft.com/en-us/azure/service-bus-messaging/duplicate-detection) (checked 2026-10-04)
- [Handle workflow errors and exceptions in Azure Logic Apps](https://learn.microsoft.com/en-us/azure/logic-apps/error-exception-handling) (checked 2026-10-04)
- [Managed identities for Azure resources](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview) (checked 2026-10-04)