Dynamics 365
Microsoft Dynamics 365 spans finance, operations, sales and service. Because it usually sits alongside the rest of a Microsoft estate, it is often the system an assistant is asked to answer from first.
Microsoft Dynamics 365 spans finance, operations, sales and service. Because it usually sits alongside the rest of a Microsoft estate, it is often the system an assistant is asked to answer from first.
What Dynamics 365 holds, and why that matters here
Dynamics 365 is modular, and Saudi deployments vary widely in which modules are live — some run finance and operations, some only sales and customer service, many run a combination assembled over years. What is consistent is that it holds the operational record and that access is licensed, so most people who need answers from it do not have direct access.
Its position inside the Microsoft estate matters practically. Identity usually already exists in Entra ID, which means the assistant can recognise a signed-in employee and answer within their existing permissions rather than asking who they are.
- Finance and operations — orders, invoices, inventory, vendor and customer records.
- Sales — accounts, opportunities, quotes and their stage; where pipeline questions are the main need, the Dynamics 365 Sales page covers that narrower connection.
- Customer service — cases, their status and history.
- Field service — work orders, scheduling and technician assignment.
- Supply chain — stock positions, transfers and replenishment.
Questions Elbi can answer across Dynamics 365
What is the status of this case?
Case state and last update, answered to the customer directly rather than by an agent reading it out.
When is the engineer coming?
Work order scheduling for field service, which is the most-asked and least-automated question in that module.
What is the stock position?
Inventory by site for staff who need a number before they commit to one.
What is this customer entitled to?
The entitlement or service agreement on record in Customer Service, so support is given on the terms actually agreed rather than on memory.
Has this invoice been settled?
Payment status against a customer account.
What did we agree with this customer?
Terms and pricing on the account record, so the answer is the same regardless of who is asked.
How Elbi connects to the Dynamics 365 apps
- Two data platforms, one identity providerDynamics 365 is not one database. Customer Service, Field Service and the other customer engagement apps keep their records in Dataverse; Finance and Supply Chain Management keep theirs in the finance and operations platform and expose them as data entities. Both authenticate through Microsoft Entra ID, so one tenant governs both connections.
- An app registration in your tenantYour Entra ID administrator registers an application for the assistant and issues its client secret or certificate. The registration lives in your tenant: removing the secret or disabling the app stops it obtaining new tokens.
- An application user with a security roleIn each Dataverse environment the registration is added as an application user and given a security role. In the finance and operations apps it is mapped to a user account whose roles limit what it reads. Either way, the role — not the assistant — decides which tables and records are reachable.
- The signed-in employee narrows itWhere staff already sign in with Entra ID, the assistant recognises them and answers within their own Dynamics access, so an agent in one business unit does not see another unit's cases through Elbi.
- Each question goes to the module that owns it"When is the engineer coming?" is answered from the Field Service work order and its booking; "has this invoice been paid?" from the customer's open transactions in Finance; "where is my complaint?" from the Customer Service case. Which module is authoritative for each question is settled during deployment, not guessed at the moment of asking.
- Writes stay on the service sideThe sensible writes are a note on a case, a new case with the conversation attached, or a callback request. Each needs the matching create privilege in the security role and can wait for a person to confirm. Finance postings are no place for an assistant to write.
Dynamics 365 security roles and control
| Direction of access | Read by default. A case note or a new case is enabled per action, needs the matching create privilege in the application user's role, and can be held for human confirmation. Finance and supply chain records are best left read-only. |
|---|---|
| Tables and columns | In Dataverse, set by the security role on the application user, with column security profiles covering sensitive columns. In finance and operations, set by the roles, duties and privileges on the mapped user. |
| Business units and ownership | Business units, teams, record ownership and any hierarchy security you use all still apply. Answers stay within the asking employee's own access, recognised from their Entra ID sign-in. |
| Credentials | The app registration, its secret or certificate, and the application user all sit in your tenant and environments. Your administrators can rotate the secret, disable the application user or delete the registration without involving us. |
| Where data goes | What is read from Dynamics serves the answer in front of it and is not copied into a separate store. Conversation content is destroyed within 24 hours, normally as the conversation closes, and it never passes to an external AI service. |
| Audit | Each lookup can be recorded against its conversation. Entra ID sign-in logs for the app registration, and Dataverse auditing for anything it changes, give your own team an independent trail. |
| If it is unavailable | If an environment is offline for an update, or Dataverse's service protection limits are reached, the assistant says it could not check and offers a person instead of answering from memory. |
What this replaces
Where Dynamics is deployed alongside the wider Microsoft estate, the assistant can do something unusually clean: recognise the employee from the sign-in they already have, and answer only what that person is entitled to see. No separate account, no second permission model to maintain, and no risk of the assistant becoming a way around access rules that were carefully set elsewhere.
For customer-facing use the value is the same as any system of record — case and order status stop being questions that require a person. For internal use it is broader, because Dynamics tends to hold the answers that cross departmental boundaries, which are exactly the ones that get asked by email and answered slowly.
The practical constraint is module sprawl. Many organisations run modules that were configured at different times by different partners, with overlapping data. Deciding which module is authoritative for each question is genuinely the hardest part of the deployment, and it is a business decision rather than a technical one.
Where Dynamics 365 questions come from, by sector
Retail and consumer
Order and delivery status at volume, with stock visibility across branches.
Field service organisations
Appointment and technician-arrival questions, which dominate contact and are almost entirely answerable from the work order.
Professional services
Project and invoice status for clients who would otherwise email an account manager.
Manufacturing
Production and supply questions asked by sales staff mid-conversation.
Which Dynamics 365 questions to connect first
In most suite deployments the best first questions sit on the service side rather than in finance: case status for customers, and appointment timing wherever Field Service is live. Both are single-record answers, both arrive in volume, and both currently need an agent to open a form and read it out.
The questions that cross modules are worth the effort next. Whether an invoice is settled before a technician is sent, or what stock a branch holds before someone promises a delivery date, are exactly the questions that travel between departments by email — and exactly the ones a signed-in employee can have answered within the roles they already hold.
If the real volume is pipeline questions from sales staff, the scope is narrower, and the Dynamics 365 Sales page describes it. On the finance side, start with single facts — a customer's open balance, a payment date — and leave period-end figures to Finance's own reporting.
What connecting Dynamics 365 involves
- Name the source module for each questionWhere Customer Service and Finance both hold something about a customer, one has to be named as the source for each question. That is a business decision, taken with the module owners, and written down before any credentials exist.
- Register the app in Entra IDYour identity team creates the app registration and its secret or certificate. It stays in your tenant, and rotating or revoking it is done by your administrators on their own schedule.
- Create the application user and a custom roleIn each Dataverse environment, a Power Platform administrator adds the registration as an application user and assigns a custom security role with read privileges on the agreed tables only. For finance and operations, the registration is entered in the environment and mapped to a user with a similarly narrow role.
- Map the configuration you actually runCustom tables and columns, renamed forms, choice fields with Arabic labels, and fields added by different implementation partners over the years are mapped to the questions they answer. Where two modules overlap, the mapping records which one wins.
- Rehearse in a sandbox environmentSandbox and test environments are where the awkward cases are tried: a work order with no booking, a case the asker's business unit cannot see, an environment offline mid-update, a customer recorded twice under Arabic and English names.
- Launch on one module, then add the nextGo live on the service questions, watch what is actually asked, then extend the security role to the next module. Each extension is a role change inside your environment, recorded in your own audit history.
Personal data in Dynamics 365 and the PDPL
A suite deployment usually holds personal data in more places than any one owner can list: customer contacts in Dataverse, service addresses on work orders, bank details on customer and vendor records in Finance. Under the Saudi Personal Data Protection Law each of those needs a purpose and a lawful basis, and an assistant reading across modules makes the question sharper rather than new.
The workable answer is to scope by module and by column. The application user's role reaches only the tables a question needs, and column security keeps bank details, identity numbers and internal notes out even where the table itself is in scope. On Elbi's side, conversation content is gone within 24 hours, and Dynamics remains the record where retention periods and deletion requests are managed.
Where customers will hear their own case or appointment details, tell them at the start of the conversation that their record will be checked, in whichever language they chose to write in.
What organisations typically see
Microsoft's own Copilot options, and where Elbi fits
Microsoft offers its own conversational layer for the suite. Copilot features inside Customer Service, Field Service and Finance help staff summarise records and draft replies, and Copilot Studio builds customer-facing agents on top of Dataverse and the wider Power Platform. For an organisation standardised on Microsoft tooling, one administration model across all of it is the strongest argument for that route.
For Saudi buyers the comparison usually turns on three checks. Test the Arabic on your own customers' messages, dialect included, rather than on a demonstration. Confirm with Microsoft where generative processing happens for your tenant and the features you enable, since that depends on region and configuration. And decide whether the assistant must also answer from systems outside Microsoft in the same conversation.
Elbi's answers to those checks are short: Arabic and English are both first languages, conversation processing runs inside the Kingdom on infrastructure you control with no external AI service involved, and Dynamics 365 is one source among the systems it connects to. Plenty of organisations will use both — Copilot inside the Dynamics forms for licensed staff, Elbi as the bilingual channel customers and unlicensed colleagues actually talk to.
On either path, the mistake to avoid is giving the application user the System Administrator role because a custom role takes longer to build. It works in the pilot and becomes the first finding in the security review.
Common questions
Whichever you point it at. Part of deployment is deciding which module is authoritative for each question, because in practice several often hold overlapping data.
Where identity is in Entra ID, yes — a signed-in employee is recognised and answered within their own permissions.
Where you enable it. Reading is the default; adding a note or raising a case is turned on deliberately and can require confirmation.
The identity model is the same; the scope is not. This page covers the wider suite — customer service, field service, finance and supply chain. If most of your questions are about pipeline, quotes and forecasts, the Dynamics 365 Sales page describes that narrower connection.
Only the ones you name. The application user is added to each environment separately, so a sandbox or test environment is read only if you add it.
Yes, once they are identified through the route you choose. They are told the booking time and status recorded on the work order; technician notes and internal comments stay out unless you decide otherwise.
Connect Elbi to your Dynamics 365 suite
A working assistant across your service, field and finance records, in Arabic and English.