Your CRM talks to Oracle — once we have established which Oracle it is.
Account, order and invoice data stays on the Oracle side; your sales team sees the part it needs inside the CRM. But “Oracle” is not a single product: until it is clear which product it is, we do not promise a scope.
“Can you connect to Oracle?” has no one-word answer
This page starts from a different place than our other ERP pages, because the question is different. When someone says Netsis, Nebim or Logo, what sits on the other side is more or less known. When someone says Oracle, it is not.
- The same sentence can describe a cloud enterprise ERP, an installation customised on your own servers over many years, or a cloud ERP managed by a separate team.
- Sometimes the ERP is an entirely different product and only the database is Oracle — a distinction that changes the answer completely.
- IT asks “can you connect”; the sales side asks “will I be able to see the balance”. The two questions look the same; they are not.
- The commercial cost of this ambiguity is this: a “yes, we integrate with it” given without knowing what sits on the other side may have to be taken back once the scope emerges.
- The picture on the sales side comes out the same in our own projects: the lead, the meeting history, the quote and the reason for a loss sit in the space where the ERP does not begin, and nothing records them on its own.
That is why on this page we make the distinction first and describe the connection second.
How is the connection built?
There is no out-of-the-box module for Oracle, and we will not say there is. The connection is built as an integration project whose scope is determined in the discovery call, using REST API, OAuth2, webhooks and import/export.
We add one more sentence to that: until it is clear which Oracle product is being discussed, we do not promise a scope. Saying “we have an Oracle integration” would be a promise made without knowing what sits on the other side; we do not make that promise before the first call. For the same reason, we also do not say that we have an “Oracle certified” or “Oracle approved” integration — we hold no such certification.
Three tools are used on the Rapitek CRM side:
- REST API — the product ships with 183 business objects out of the box, and each one is published in the REST API with its own data and schema endpoint; access is authorised with OAuth2, and no integration is ever built by sharing a user's password.
- Outgoing webhooks — CRM events are delivered to the external system signed; a failed call is retried and the target address is verified.
- Import/export — a four-step wizard; in organisations with long approval processes, a starting point that does not delay the first benefit.
The limits of these three tools are measured, not estimated: the REST API exposes object and field definitions through the describe endpoint, processes up to 200 records in a single bulk request, and carries 25 sub-requests at once in a composite call. The import wizard works across more than 75 objects, up to 100,000 rows per job and 25 MB per file. Our general approach is on the integrations page; the same framework applied to a single-product ERP is on our Netsis integration page.
First: which Oracle?
| What sits on the other side | The first question we ask in discovery |
|---|---|
| Cloud enterprise ERP (e.g. Fusion / ERP Cloud) | With what authorisation can the integration layer be reached, and who defines that access? |
| An installation on your own servers, customised over many years (e.g. E-Business Suite) | Which modules are in use, and is an externally exposed interface defined today? |
| A cloud ERP managed by a separate team (e.g. NetSuite) | Where will authority over which data stay, and which record will flow in which direction? |
| A long-lived, industry-specific Oracle product | Is there an interface that gives data out today, or are we talking about periodic extracts? |
| The ERP is another product; only the database is Oracle | Is there an interface on the application side? We do not recommend connecting directly to the database as a first solution. |
Wednesday, 09:50 — IT asks “Can you connect to Oracle?” Here is how we walk through it:
-
1
The distinction is made in the same call
Which Oracle product, where it runs, who manages it — these three questions are answered first. Until the answers come, neither scope nor timeline is written down; this is not the half hour the call loses, it is the half hour the call gains.
-
2
Who holds access is put in writing
Is the party that defines the interface your own IT department, your Oracle partner, or your service provider? The boundary of responsibility is drawn at the start, not argued over later.
-
3
The sales side is not put on hold
If the approval process on the Oracle side is long, the CRM rollout starts on an extract-based footing. The sales team begins keeping records from the first week; when the connection is ready, the same scope is moved onto the API.
-
4
Balance and invoice visibility comes first
This is what we recommend as the first flow: account balance, due date and invoice header information sit as fields on the customer record. They are visible before a quote is written.
-
5
IT's questionnaire gets a written answer
Data location, the sub-processor list, authorisation and audit logging are written out on our security page; we also fill in your assessment questionnaire ourselves. We also state in writing that we hold no certification.
-
6
The scope comes out in writing, then the work starts
The field mapping table, flow direction, frequency and price are shared in writing. After the discovery call we give you a date, not a range.
Flows that can be built between Oracle and Rapitek CRM
Matching customer and account records
Records are matched using the tax number or the customer code on the Oracle side as the key. The matching rule and conflict scenarios are defined in the written scope.
Balance, due date and risk visibility
Account balance, overdue amount and risk limit are transferred onto the customer record. Transfer frequency is set in the scope; authority stays on the Oracle side.
Tracking order and invoice information
Order and invoice header information can be followed as a list on the customer record. Authority over the document stays in the ERP; the CRM adds a visibility layer for the sales team.
Notifying the ERP side of a won opportunity
A signed webhook that passes order information to the external system when an opportunity is won can be set up. Calls are signed, and a failed call is retried.
A fast start with a periodic extract
While access approval on the Oracle side is pending, the account and balance extract is transferred with the four-step wizard. It works within the limits of 100,000 rows per job and 25 MB per file.
Authorisation and audit trail
Profiles, permission sets, role hierarchy and record sharing are supported; field-level change history is kept. This is where enterprise audit questions get their answer.
Which method, and when?
| Method | What it does | When it is preferred |
|---|---|---|
| REST API (183 business objects out of the box, each with its own data and schema endpoint) | The external system reads and writes records in the CRM; it is authorised with OAuth2, the schema is read from the API, and bulk and composite requests are supported | When an integration layer is defined on the Oracle side and the flow is meant to run automatically |
| Outgoing webhooks | Events in the CRM (e.g. opportunity won) are delivered to the external system signed; a failed call is retried | In flows that need event notifications from the CRM towards the ERP |
| Import (Data Hub) | Excel/CSV extracts are transferred with the four-step wizard: upload, map fields, preview, run. Export is done in the same module; we have not measured its limits | While the access approval process is long; to start without keeping the sales side waiting |
| Third-party integrator | Your consultant who knows the Oracle side can write the connection themselves using the same REST API; we provide the schema, OAuth2 access and the field mapping table | If you work with an established consultant team on the Oracle side |
What we have verified
How is the Oracle connection put into service?
-
1
Distinction and discovery
Which Oracle product, where it runs, who manages it, and whether an externally exposed interface is defined — all of this is established. We recommend that IT and the team that knows your Oracle side be in this call.
-
2
Scope, authorisation and the boundary of responsibility
Which data flows in which direction and how often, and who will define the interface, are written down here. The field mapping table and any fee are shared in writing — no surprise line items.
-
3
Configuration and a test transfer
Objects, fields, permissions and reports are set up on the CRM side; two-way validation is done with sample data. Duplicate-record and conflict scenarios are exercised here.
-
4
Training and go-live
Team training and close follow-up in the first week. We do not commit to a timeline before discovery; after the discovery call we give you a date, not a range. If access approval on the Oracle side drags on, it starts with an extract-based flow and is moved onto the API afterwards.
Our limits: what we do not promise on this page
There are five things people ask about when Oracle comes up. We do not promise any of the five, and we write down why.
- We do not say “Oracle certified / approved integration”. We hold no such certification and will not claim one without it.
- While it is unclear which Oracle product is involved, we do not promise a scope. A promise made without knowing what sits on the other side gets taken back once the scope emerges.
- We do not say “your stock will be in sync”. Authority over the stock record stays on the ERP side.
- We do not say that the order → invoice → collection chain will flow on its own. That chain is built into the product, but we do not think it is right to sell it as an automated accounting flow.
- We do not promise manufacturing and MRP automation. Bill of materials and production line definitions exist in the product; we cannot today point to a reference for work order execution.
We have written the reason for the last three, and “what can be done instead”, in one place, line by line: the three things we do not promise. Rapitek CRM also does not issue e-Invoice or e-Archive documents and is not a GİB (Turkish Revenue Administration) special integrator.
Data location: your data is held in the European Union — the database in Helsinki (Finland), files in Frankfurt, backups in Falkenstein (Germany). We have no component in Turkey and we have no region-selection feature. This is a transfer abroad under Article 9 of KVKK (Turkey's data protection law); we establish your legal basis for the transfer together during the contract process. The detail is on the security page and in the KVKK privacy notice.
Certification: we hold no ISO 27001 or SOC 2 certification. We fill in your enterprise security assessment questionnaires and describe the architecture in writing; we do not give a written service level (SLA) commitment.
Scope comes out of discovery; plan prices are out in the open
Until it is clear which Oracle product you are on, we do not promise a scope; the price comes out together with the scope. Plan prices, though, we publish in one place, with their actual figures.
Three plans, a scope table and separately priced items, all on one page.
Frequently asked questions about Oracle integration
Is CRM integration with Oracle possible?
Is there a ready-made Oracle module in Rapitek CRM?
We do not know exactly which Oracle product we use. How do we proceed?
Is this an Oracle certified integration?
Can you connect directly to our Oracle database?
Can our Oracle consultant write the connection themselves?
We use Oracle NetSuite. Does it make a difference?
Our IT team sends a security assessment questionnaire. Do you fill it in?
Will our stock stay in sync with the CRM?
Can we issue an e-invoice from the CRM?
Does it replace Oracle?
Will synchronisation be real time?
How long does the rollout take and what does it cost?
Where is our data held?
Let us establish which Oracle it is, in 30 minutes
Bring your IT manager to the call as well; let us make the distinction together and settle the scope and the method in the same call.
The scope of the rollout, and any fee for it, is worked out in the discovery call and shared in writing.
