Create a Corporate Tool
Give your staff a shared place to manage records, make decisions and follow work through, next to the systems your company already uses.
- Work shaped around your operations
- Access that follows responsibility
- Your ERP and CRM, inside the work
Give your teams the tool their process deserves.
Companies lose time in the gaps between their systems: spreadsheets passed around, approvals buried in email, the same data typed twice. A corporate tool gives your staff one place to manage the work, make the decisions and follow each case through.
Wildo supplies the application foundation, the access model and the connections to the systems of record your company already runs: Odoo, SAP S/4HANA, Salesforce, Microsoft Dynamics 365, Business Central, NetSuite, or any OData service. You bring the process, the people responsible for it and the rules those systems have to keep.
Your developers or your usual integrator build it, with a coding agent such as Claude Code or Codex. The code lives in your company’s repository and runs on your infrastructure, behind your identity provider, with your IT team holding the roles and the audit trail.
What your tool starts with
Your company’s sign-in and roles
Staff sign in through your identity provider with OpenID Connect or SAML, and accounts can be provisioned from your directory with SCIM. Roles separate who can see a record, who can change it and who takes a decision.
The systems you already run
Declare your ERP or CRM once, then choose for each kind of record: read it where it lives, keep a local copy current, write changes back under the system’s own rules, or keep both sides in step with each field’s owner declared. The tool never confuses which system owns what.
A record of who did what
Security-relevant actions are written to an audit trail your security team can route to its SIEM, including every change the tool sends to another system and who approved it.
Example: Supplier onboarding for a purchasing department
A buyer opens a request for a new supplier. Compliance checks the documents and finance approves the payment terms, each under its own role. The tool reads the supplier list from the company’s ERP to show whether the supplier is already known. Once finance approves, it creates the supplier in the ERP, exactly once, and records who approved it. The tool owns the request and every decision on it; the ERP stays the owner of the supplier record.
For engineers
It starts with the work
The first step is a conversation about the work itself: what moves through the process, who is responsible at each step, which decisions need approval and which system owns each piece of information. Those decisions become the application’s specifications, kept as files in its own repository.
Your systems of record, declared once
Each ERP or CRM is declared once, by name, with the address and credentials each environment supplies. It is reached with the company’s own service identity, never with a person’s account, and the application boots without contacting it, so an ERP outage does not stop the tool. Each resource then chooses how it uses that system:
| System | Read where it lives | Local copy kept current | Write back | Two-way sync |
|---|---|---|---|---|
| Odoo | Yes | Yes, only what changed | Yes, and actions such as posting an invoice | Yes |
| SAP S/4HANA | Yes, OData v4 and v2 | Yes, only what changed on v4 services | Not yet | Not yet |
| Salesforce | Yes | Yes | Yes | No: last writer wins |
| NetSuite | Yes | Yes | Yes | No: last writer wins |
| Microsoft Dynamics 365 | Yes | Yes, only what changed | Yes, version-checked | Yes |
| Business Central | Yes | Yes, only what changed | Yes, version-checked | Yes |
| Any OData v4 service | Yes | Yes, only what changed | Yes, version-checked, and actions | Yes |
What holds for every system: each write is sent once and audited, and a write whose outcome cannot be known is never sent again blindly: a pipeline holds it for an operator to answer. Two-way sync declares who owns each field and what happens when both sides changed. A webhook from the ERP can ask for just the records it names to be read again. Synced fields show staff where they came from and how current they are, and operators have a run history, a reset and the conflicts to decide. A person who has been erased is not imported again, and the privacy notice names each system as a source of the personal data it holds.
Each system is checked against a simulator faithful to its vendor’s protocol, Odoo also inside a running application; the first runs against live tenants come next.
The tool is built from them
Wildo’s playbooks turn the specifications into a build plan. A coding agent implements it one task at a time inside the application, on Wildo’s engine. Each result lands as a commit your team can review, keep or revert.
Today that method is the one a commercial product follows, so the market, pricing, brand and website work it includes is set aside for your tool in the conversation. A creation line of its own for internal tools is in the next framework release. It leaves that work out and sets up a single owner organization with no billing. Accounts come by invitation only, so there is no public sign-up. If your company signs in through its identity provider, the line turns on single sign-on for its people, and directory provisioning when its directory supplies their accounts.
It runs where your company runs
Deploy with Docker Compose or Kubernetes on your own infrastructure. Several applications can share one Wildo platform, so the second tool reuses the operating services the first one set up.
Where it is going
- A creation line for internal tools: one owner organization, accounts by invitation or from the company’s directory, sign-in through the company’s identity provider, no public sign-up, billing or website, and specifications that start from the process rather than from a market. Requiring the identity provider for everyone at the company’s domain comes after it.
- Every system confined by company: data from a multi-company ERP is already confined to the organization units entitled to each Odoo company; Dynamics 365 business units, Business Central companies, SAP company codes and NetSuite subsidiaries follow.
- More of each system: writes to SAP through its own protection handshake, certificate-based sign-in for SAP communication users, and first runs against live tenants of each vendor.
- More systems: any OData v4 service is reachable today; adding a vendor is one declared description of its protocol and credentials, which a package can extend without changing the engine. Beside them, the module registry opens with more than 200 connectors to everyday business services at launch.
Go deeper
The parts of Wildo this page draws on, each explained on its own page.
- Internal tools & business software An application tailored to how your teams manage records, make decisions and work with the ERP and CRM they already run.
- Providers, OAuth & external data Call provider operations, connect customer accounts, and read, write back or synchronize the ERP and CRM a company already runs.
- Identity, organizations & access Manage users, customer organizations, roles and service identities across application operations.
- Resources, APIs & business logic Define business objects and operations once, then use them across persistence, APIs and standard interfaces.
- Audit trails & data privacy Record accountable actions and handle personal-data requests, retention and erasure through application services.
- Back offices & supporting services Administrative interfaces and background services for the people and processes operating your application.
Less time on the tool, more on the process it serves.
Wildo carries the application foundation and the discipline of working with your systems of record. Your people bring the knowledge of how the work should be done.
Apply for the private beta.
The private beta opens with the first release, and we are choosing the companies that take part. Tell us what you want to create: we will say plainly whether it fits and what happens next.