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: the scope is set once it is clear which product it is.
“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 the REST API, webhooks and import/export.
We add one more sentence to that: the scope is set once it is clear which Oracle product is being discussed. 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. The integration is not Oracle certified or Oracle approved; we hold no such certification.
Three tools are used on the Rapitek CRM side:
- REST API: every record in the CRM, from lead to quote, from invoice to task, can be read and written through it; access is granted with permissions, and no integration is ever built by sharing a user's password.
- Outgoing webhooks: the external system is notified securely of CRM events; a notification that does not arrive is retried, and the target address is validated.
- 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 gives the field structure of each record type, handles up to 200 records per bulk transfer request, and accepts up to 25 operations in a single request. 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 webhook that passes order information to the external system when an opportunity is won can be set up. The receiving system can verify the notification came from us, and a notification that does not arrive 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 | The external system reads and writes every record in the CRM; access is granted with permissions, the field structure is read from the API, and bulk transfers and several operations per request 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 notified to the external system securely; a notification that does not arrive 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 | 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 field structure, the access permissions 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.
Scope and setup terms
Five questions come up whenever Oracle is discussed. Here is how each one is handled:
- Certification: the integration is not Oracle certified or Oracle approved; we hold no such certification.
- The scope is set once the Oracle product is known. A scope written without knowing what sits on the other side would have to be taken back later.
- Stock stays on the ERP side. Authority over the stock record stays in your ERP.
- The order → invoice → collection chain is built into the product. It is not sold as an automated accounting flow.
- Manufacturing and MRP: bill of materials and production line definitions exist in the product. Work order execution is new; if your process depends on it, let's try it together in the demo.
The reasons for the last three, and what can be done instead, are in one place, line by line: scope and setup terms. e-Invoice and e-Archive documents stay with your current setup: Rapitek CRM 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. A written service level (SLA) commitment is not offered.
Scope comes out of discovery; plan prices are out in the open
Once it is clear which Oracle product you are on, we set the scope and the price together. 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. Then we open your 7-day trial account; no credit card required.
