Cirqll data in your own database: how to keep your pipeline history

Why put Cirqll data in a database of your own?

Cirqll is built to organise your day-to-day sales and relationship management, and it does that well. But a CRM mainly remembers how things stand right now. When an opportunity moves to another stage, its value changes or it gets archived, you see the new situation. What it looked like last month is hard to retrieve.

Yet those are exactly the questions that come up in a management meeting:

• How big was the pipeline at the end of last quarter, and has it grown?
• How long does an opportunity stay in the "Proposal sent" stage on average?
• Of the opportunities open in January, how many were eventually won?
• Does the won revenue in Cirqll match what was invoiced in accounting?

A direct connection between Cirqll and Power BI, as described in connect Cirqll to Power BI, works well for a current dashboard. For these historical questions you need a place that remembers on its own. That is a database of your own.

Which Cirqll data do you load into your database?

Through the Cirqll API you can fetch customers, contacts, opportunities, assignments, contracts, tasks, appointments, notes and custom fields, among other things, as far as the connected user has rights to them. We wrote about the possibilities in more detail in Cirqll API: what you can do with it.

For a first database you do not need everything. Start with what your questions require. For pipeline history that is usually:

1. Opportunities, with name, value, percentage, owner, customer and the dates on which the opportunity was created and last changed.
2. Customers, so you can group opportunities by customer, sector or region.
3. Users, to assign opportunities to a salesperson.
4. Custom fields you created in Cirqll yourself, such as a lead source or product group. That is often where the most valuable information sits.

Contracts and assignments can be added later, when you also want to follow what happens after an opportunity is won.

How do you fetch Cirqll data without reloading everything every time?

The Cirqll API works with OAuth2 and JSON. A few properties make loading into a database much simpler (checked against the public documentation on 20 October 2026):

• Filtering and sorting. You can filter results with operators such as "greater than or equal to", and sort them. Opportunities have a field with the date of their last change, so on each run you only fetch what has changed since the previous one.
• Pagination. You fetch data in batches. Useful when you load the full history the first time.
• Loading related data and limiting fields. You can, for example, load the customer together with the opportunity in one go, and request only the fields you need.
• Webhooks. For almost every resource you can set up webhooks on create, update and delete. That way you also hear about records that disappear, something you easily miss with periodic fetching alone.

Keep two limits in mind. Cirqll allows up to 100 requests per minute per client, and all dates are returned in UTC. That sounds like a detail, but an opportunity won at 00:30 Dutch time still falls on the previous day in UTC. Convert the time zone once in your database, not separately in every report.

How do you build history with your Cirqll data?

A database only remembers what you record in it. If you overwrite the opportunities table with the latest state every night, you still have no history. There are two common ways to solve this:

• Daily snapshot. Every night you save a copy of all open opportunities, together with the date. Simple to build and easy to understand. You can see per day how big the pipeline was and which stage each opportunity was in.
• Tracking changes. You only store a new row when something about an opportunity changes, with a "valid from" and "valid to" date. More economical and more precise, but harder to build well.

For most SMEs a daily snapshot is the right place to start. The number of opportunities in a CRM is rarely large enough for storage to become a problem, and reports on top of it are easier to build and check.

Important: history starts on the day you start recording. Changes made in Cirqll in the past cannot be recovered afterwards. That is a good reason not to wait too long.

Which database should you choose for your Cirqll data?

You do not need to think about this for long. An ordinary relational database, such as PostgreSQL or SQL Server, is more than enough for this purpose. More important than the brand are these questions:

• Can Power BI reach it easily? Both databases mentioned can be connected with a standard connector.
• Where does it run, and who manages it? A managed cloud database saves you maintaining servers and backups.
• Can it grow with you? If you later want to add accounting, time tracking or planning, it helps if that can go into the same database.

That last point is where the real gain is. Once Cirqll data sits next to your invoice data, you can finally put won opportunities next to invoiced revenue. How this fits into the bigger picture is explained in what is a data foundation.

An example: from "where do we stand?" to "how is it developing?"

A fictional but recognisable example. A consultancy with five salespeople has worked with Cirqll for a few years. Every Monday the team looks at the pipeline in Cirqll, and at the end of each quarter someone makes an export to Excel to keep the position. Those exports sit in a folder, each laid out slightly differently.

Management wants to know why the second quarter was disappointing. Were there fewer new opportunities, did they stall longer or were more of them lost? The separate exports cannot answer that.

The approach:

1. A small database is set up with four tables: opportunities, customers, users and a table with daily snapshots of the opportunities.
2. A scheduled connection fetches every night the opportunities changed since the previous run, and records a snapshot of all open opportunities.
3. The old quarterly exports are loaded once as a starting point, with the caveat that this history is coarser.
4. In Power BI a report shows the pipeline per week, the lead time per stage and the win rate by month of creation.

After a few months the team can see not only where they stand, but also how they got there. Which other pages such a report can have is described in the Cirqll sales dashboard in Power BI.

Where does it go wrong with Cirqll data in a database?

• No monitoring on the connection. A nightly run that stops for a week leaves a gap in your history that you can never fill. Make sure someone gets an alert when something fails. Make.com error handling explains how to approach that.
• Expired tokens. A Cirqll access token is valid for 15 days, a refresh token for 30 days. Make sure the connection refreshes tokens in time.
• Renaming stages without agreement. You name the stages in Cirqll yourself. If you rename one, old and new snapshots appear to describe different things. Record which stage names belong together.
• Forgetting custom fields. Your own fields are what give your reports meaning. Include them from the start, even if you do not use them straight away.

Help with your Cirqll data in a database

Setting up the connection, the database and the history is what we mean by data engineering. The reports on top fall under dashboarding. Read more about our partnership with Cirqll and the Cirqll Power BI Connector on our Cirqll page, and see which other systems we can connect under integrations.