This request usually comes from a sensible place: the data is useful, most people cannot get at it, and everybody already lives in Teams. Widening access is a genuine productivity opportunity.

It also changes your risk profile, because you are about to let people ask questions who never had a route to the ledger before.

Teams
Web Portal
Chatbot
Role Inheritance
Sourced Answers
Audience Mix
Logging

The Surface Is Not the Project

Connecting an answer to a chat surface is a well trodden integration. What determines whether the deployment succeeds is everything underneath it, and that layer is the same whichever surface you pick.

This matters because it means you can choose the surface on convenience grounds and should choose the platform on substance grounds. Getting that the wrong way round produces a very convenient way to distribute unreliable numbers to a wider audience than before.

Surface: Teams, a portal, a chatbot or several at once. A delivery decision.
Substrate: Whether the answer is correct, permitted, sourced and logged. The actual project.
Same underneath: The tool layer, the security model and the audit record do not change by surface.
Choose accordingly: Surface on convenience, platform on substance.
Asking a question and getting a sourced answer

Asking the ERP a question

Putting JD Edwards inside Microsoft Teams makes asking easy. Whether the answer is right depends on the work underneath, which is the actual project.

I can almost chat with my ERP system. I can chat with my P&L, chat with my balance sheet, and understand what is causing this flux.

Jason Yocum, on the AgentCFO podcast

Spend the effort on grounding and permissions. The chat window is the part users see and the smallest part to build.

Permissions Get Harder When Access Widens

A conversational surface inside Teams reaches people who never had a JD Edwards login, which is the point and also the risk.

The clean answer is that queries run inside an authenticated session carrying the requesting person's environment and role, so entitlement is inherited rather than invented. The alternative, a shared identity with filtering applied afterwards by the chat platform, means maintaining a second security model and hoping it agrees with the first.

Inherit, do not invent: The session belongs to the person asking, so visibility matches the application.
Map the identity: Their Teams identity resolved to their JD Edwards user, so entitlement follows automatically.
People without logins: Decide deliberately what a person with no JD Edwards account may see, if anything.
Scope exclusions: Sensitive areas such as payroll placed entirely out of reach regardless of surface.

The Answer Quality Requirements Do Not Relax

If anything they tighten, because a conversational answer in Teams carries an air of authority and gets forwarded. A wrong number in a spreadsheet is one person's mistake; a wrong number pasted into a channel becomes organisational fact within a day.

Real queries: Every figure produced by an actual query against live data, never recalled.
Rows attached: The records behind the number available immediately, even in a chat surface.
Read time stated: Because availability and balances move during the day.
Declines to guess: Where the data does not support an answer, it says so rather than producing something plausible.
ChatFin compared with generic AI agents

Different Audiences Ask Different Things

Widening access changes the question mix, and it is worth anticipating. A single substrate serves all of these, but the framing and the permitted scope differ.

In practice the operational questions arrive in far higher volume than the finance ones, and they are frequently the ones that save the most time because they currently interrupt somebody.

Operations: Where is this order, is this item available, when is the delivery due.
Sales: What is this customer's position, why is this order on hold, what is their credit exposure.
Finance: What is this balance, what makes it up, what changed against last period.
Management: Short sourced answers to specific questions without a three day analyst detour.

What to Log and Why

Logging in this context serves two purposes and the second is the one nobody anticipates.

The first is control: who asked what and what was returned. The second is product insight, because a list of the questions people ask is the most reliable guide you will ever get to which reports are worth building and where your process problems are.

Who and what: The requester, the question, the query executed and what was returned.
Failed answers: Questions the system could not answer, which point at genuine gaps.
Frequency: Repeated questions, which usually indicate a missing report or a broken process upstream.
Volume by audience: Which groups adopt it, which tells you where the next investment belongs.
A specific question answered in seconds, sourced

Practical Deployment Advice

Two things consistently determine whether this is adopted or abandoned after a fortnight.

Start with one audience: Usually customer service or finance, so you can tune the answers before wider release.
Seed the common questions: Publish the five questions it answers well, because an empty prompt box gets ignored.
Handle failure gracefully: A clear statement that it cannot answer, with a route to a person, preserves trust.
Measure adoption: Questions per user per week, which tells you honestly whether it is useful.

Where ChatFin Fits

ChatFin answers from live JD Edwards data inside authenticated sessions that carry the requesting person's role, with the supporting rows attached to every figure, and delivers into the surfaces your people already use.

Because the substrate is the same regardless of surface, adding a second delivery channel later is a configuration rather than a project. Our page on conversational financial analysis covers the underlying requirements in more depth.

ChatFin as the finance system of intelligence

Choose the Surface for Convenience, the Platform for Substance

ChatFin delivers JD Edwards answers into Teams, a portal or a chat surface, with queries running inside authenticated sessions that inherit each person's role and every figure carrying the rows behind it.

A wrong number in a spreadsheet is one person's mistake. The same number pasted into a channel is organisational fact by tomorrow.

Book a Demo

Frequently Asked Questions

Can employees ask JD Edwards questions inside Microsoft Teams?

Yes, and the surface is the straightforward part. What determines success is the layer underneath: whether the answer is produced by a real query against live data, whether the requester's own JD Edwards role governs what they can see, whether the supporting rows are attached, and whether everything is logged. That substrate is identical whether the answer appears in Teams, a portal or a chatbot.

How do permissions work when people have no JD Edwards login?

That has to be a deliberate decision. The clean design is that queries run inside an authenticated session carrying the requesting person's environment and role, with their chat identity resolved to their JD Edwards user so entitlement is inherited. For people with no JD Edwards account, decide explicitly what they may see, if anything, rather than defaulting to a shared identity with filtering bolted on.

What should we log?

Who asked what, the query executed and what was returned, which serves the control requirement. The second purpose is the one nobody anticipates: the list of questions people ask is the most reliable guide you will get to which reports are worth building, and repeated questions usually indicate a missing report or a broken process upstream.

Related Articles