Taurza reads pipeline and closed deals. It writes nothing back. That is not a gap in the roadmap and it is not a limitation we are working around. It is the boundary the product is built on, and it is worth explaining plainly because most commission tools ask for the opposite.
If you remember one product stance from Taurza, remember this one. We calculate and certify. We do not write commission fields into your CRM, and we never hold or move money. Payroll pays.
The questions we actually get
Security reviews and RevOps teams ask a predictable set of questions about this. Here are the answers, without hedging.
Does Taurza need write access to calculate?
Short answer: no. Pipeline and closed transactions can be read. Attainment and commission are calculated from the plan of record plus those reads. Nothing about the math requires writing a field back.
Write access is usually sold as convenience, and the convenience is real for about a week. Then a closed amount gets corrected after a sync, and now there is a commission field holding a stale value that disagrees with the deal record. Reversing that is harder than never writing it, and the cleanup lands on the team that did not ask for the feature.
What does read-only actually protect?
More than most people expect when they first hear it framed as a restriction:
- Your CRM stays the commercial system of record, with one definition of a closed deal.
- Security review gets a short story: least privilege, no field writes, no fund movement.
- Finance certifies from the plan of record plus read-only inputs, so the inputs cannot drift under them.
- RevOps avoids inheriting another automation surface where a sync can race a human edit.
- A temporary field never becomes permanent tribal knowledge that nobody can safely delete.
The last one is underrated. Every write path eventually becomes something a new operations hire is afraid to touch, because nobody remembers which integration depends on it.
What stays ours as the customer?
Read-only does not remove ownership. It clarifies it, and the split is deliberate:
- Credentials and access decisions.
- Plan accuracy and the language of the plan itself.
- Payment decisions and the payroll run.
- Compliance with wage and employment law wherever you employ people.
Commercial truth stays in the CRM. Compensation math sits next to the plan. Payment stays in payroll. Outputs are not accounting, tax, legal, or employment advice; the platform calculates and certifies, and you decide what to pay.
What if a vendor insists they need write access?
Ask them these, in this order, and listen for whether the answers are specific:
- Exactly which fields do you write, and on which objects?
- What happens when a closed amount changes after your sync, and who wins, the CRM edit or your field?
- How long does an incorrect value stay visible to reps before it is corrected?
- How do I audit the second ledger you have just created?
- How do I reverse a bad write cleanly, without a manual cleanup project?
Those five questions usually end the write-access conversation, because the honest answer to the second one is that it depends on timing, and the honest answer to the fifth is that you cannot. If a tool cannot calculate your plan without writing into your CRM, it is worth asking what else it expects to own.
The boundary, in one place
Stated as plainly as we can put it, so it can be pasted into a security questionnaire without translation:
- CRM for commercial truth. Ladder for certified math. Payroll for payment.
- No commission fields written into the CRM.
- No money held or moved inside Taurza.
- Plan of record remains customer-owned.
- Certification stays clause-backed and openable on any line.
- Payroll remains the payer.
What this means for getting started
The practical effect of a read-only boundary shows up before anyone sees a rate, because it changes who has to approve the project and what they have to approve.
- The access request is a read scope on pipeline and closed transactions, which is a conversation most security teams can finish in one pass.
- There is no field mapping exercise, because no fields are being written. What would normally be the longest part of a commission rollout does not exist.
- There is no rollback plan to design for CRM data, because nothing in the CRM changes.
- The first thing to load is the signed plan, which is work only finance can do and does not depend on an integration at all.
- Reps see a ladder before anyone has touched a CRM record.
Teams often expect the opposite order, where the integration comes first and the plan gets loaded once the data is flowing. Reversing that is deliberate. The plan of record is the thing the numbers have to trace back to, so it is the thing worth getting right first.
Why this is a product choice, not a checkbox
Plenty of tools would describe read-only access as a phase they intend to grow out of. We treat it as the thing that makes the rest of the product trustworthy, and the reasoning is practical rather than philosophical.
Read-only is how you keep RevOps from policing another source of truth. It is how you keep a certified number from being overwritten by a sync race at the worst possible moment. It is how a security review stops being the blocker on a comp project. And it is how reps get a marginal rate on their phone without anyone turning the CRM into a payroll system by accident.
Start there on a trial. One CRM connection, read-only, full product on, no charge for fourteen days. The point of the trial is not to see a dashboard. It is to prove that calculation can live outside the CRM without losing fidelity, and that certification gets clearer when write access was never part of the request.
Keep the boundary. Keep the CRM clean. Keep the math certified where the clause lives.