Worked example: purchasing app
A worked-through example — when a Custom AI App is the right choice and how the building blocks fit together
The overview describes when a Custom AI App is a better fit than an assistant or a workflow. This page works through one concrete example so you can transfer the pattern to your own cases.
The scenario
A purchasing team regularly sends queries about rescheduled delivery dates to many suppliers and has to keep track of the replies. Done by hand, that means: maintaining spreadsheets, writing emails one by one, reading replies, and updating status manually.
As a Custom AI App, this turns into one continuous flow:
- An export file from the ERP system (changed delivery dates) is uploaded.
- The app automatically writes the matching follow-up email per supplier.
- Incoming replies are read by the AI and translated into a clear status (date confirmed, new date proposed, question raised).
- The team sees at any time which queries are open, confirmed, or answered.
Why a Custom App fits here
The overview names three signals — all three apply here:
- Structured inputs — the ERP export is a table, not free chat input.
- Results to review and confirm — buyers want to see and approve every supplier reply, not adopt it blindly.
- A multi-step process with state — a query runs through several steps over days; that state has to persist.
On top of that, two properties that a chat assistant or workflow doesn't capture well:
- Its own data store — the app keeps its own database of queries, suppliers, and status.
- Background jobs — emails run on a fixed schedule and a daily digest is sent automatically, even when nobody has the app open.
Rule of thumb: as soon as a task needs its own state over time and a guided interface, a Custom App is usually the better choice. For one-off question-and-answer tasks, the chat assistant stays simpler.
How it's built
The app is a standalone web application with its own frontend and backend, embedded into meinGPT via an iframe. meinGPT handles sign-in and securely forwards the user context to the app.
| Building block | Role |
|---|---|
| Interface (iframe) | Table view of queries, detail dialogs, approval of replies |
| Backend | Own database, import logic, email sending, AI calls |
| Auth proxy | meinGPT as the identity source; the backend verifies every request against the meinGPT JWT |
| Email integration | Sending and receiving via a mail API (e.g. Microsoft Graph), credentials stay server-side |
| AI evaluation | Incoming replies are passed server-side to a language model and translated into a status |
The security-critical part — how your app only accepts requests coming from meinGPT and verifies the user context — is described separately under Security & Authentication Proxy.
The flow in detail
Import — The buyer uploads the ERP export. The app creates a query per row and matches it to the right supplier.
Outbound — For each open query, the app generates a follow-up email and sends it via the configured mail API. Sending runs on a fixed schedule in the background.
AI evaluation — When a reply arrives, the language model reads it and proposes a status: date confirmed, new date, or question needed.
Review & approve — The buyer sees the reply and the AI's proposal side by side and confirms or corrects the status. Nothing is marked final without human approval.
Overview — A daily summary goes out automatically; the overview shows at any time what is open, confirmed, or answered.
The transferable pattern
Independent of the specific purchasing case, the pattern generalizes:
- Structured data in (upload or interface) → AI processes → human reviews and approves → state persists.
- meinGPT provides sign-in and identity; your app holds the data, the logic, and the connection to third-party systems.
- Credentials for email, ERP, or other APIs stay server-side in your app — the frontend only calls your own backend.
The same pattern carries, for example, for complaint handling, quote follow-ups, or processing incoming forms.