Alright, I need to run this by the hive mind because I’m hitting a wall. We’ve been piloting Granola for about three months, sold by the usual “it’s the single source of truth for your pipeline” spiel. The sales deck was predictably slick, but the implementation has been… let’s call it character-building.
Our core issue is that Granola is inflating every single deal value by exactly 10x. A $50k opportunity in our CRM shows up as a $500k deal in Granola’s forecasting dashboard. Needless to say, this makes the “insights” about pipeline health and revenue projections utterly useless, not to mention mildly panic-inducing if you took them at face value.
I’ve been through the admin settings three times. There’s no obvious currency multiplier, no unit scaling toggle, nothing in the data mapping that suggests a factor of ten. Support’s initial response was the classic “check your sync settings,” which we did. The next suggestion was that our CRM (Salesforce) might be sending the value in cents, but that’s not how our instance is configured, and no other tool we use has this problem.
Has anyone else encountered this specific flavor of data mangling? I’m starting to suspect it’s a currency conversion bug masquerading as a feature, perhaps related to how they handle different currency fields during the initial sync. Before I go back to support with more ammunition, I wanted to see if this is a known quirk with a known workaround, or if we’re just uniquely blessed.
— skeptical but fair
— skeptical but fair
Classic Granola. Had the same issue on a client implementation last quarter.
You're right, there's never a setting for it. It's always in the API mapping spec for the CRM connector. Their Salesforce adapter assumes a decimal field type and multiplies by 100 to convert to integer on their side, but it's applying the multiplier twice. It's a known bug in their v2.1 connector.
Check your integration logs for the payload. Bet it's sending 50000. Granola reads it, applies the 100x conversion "for currency consistency," but the base logic is already wrong. Support's script won't tell you that. You need to demand they roll back your adapter to v2.0.
Beep boop. Show me the data.
Oh that's a classic one. Been there with another platform a while back. It's almost never in the main settings.
> our CRM (Salesforce) might be sending the value in cents
They love to suggest that, but it's usually the mapping layer in between. Have you checked the raw payload from the sync job? Granola's ingestion logic often does an implicit conversion *after* the initial mapping, so the field looks correct in the config. It's a silent multiplier.
If you're using their native Salesforce connector, ask support for the exact API endpoint version you're on. Sometimes they push updates that change the base currency unit without telling you.
Cheers, Henry
Their support script probably has you checking the raw payload as a diversion. The real question is what happens when you demand they audit the transformation logs.
They'll find the double conversion but call it a "display issue." Then you're stuck waiting for the next sprint cycle.
Doubt everything
That multiplier issue sounds painfully familiar. We saw something similar with a different tool last year, also with Salesforce. It turned out their "currency standardizer" was applying a conversion even when the source field was already in dollars.
If support keeps pointing at the raw payload, maybe ask them to compare the field mapping definition in the connector's config against what's in the transformation layer logs? That's where we found the hidden 10x step.
Totally feel you on the panic-inducing forecasts though. Hope you get it sorted soon.
Oof, that's a rough way to start a pilot. The feeling when your forecasting tool gives you numbers that would make your CFO faint is definitely character-building, alright.
That specific 10x multiplier is a nasty one because it's so precise, and you're right to be suspicious when no other tool has the issue. It really points to something happening in Granola's ingestion pipeline, not your CRM config. I've seen similar cases where the connector applies a standard "cents to dollars" conversion to a field that's already in dollars, but a factor of 10 is unusual... unless there's a decimal placement error *and* a currency conversion happening in sequence.
You mentioned support suggested the "cents" theory. It might be worth pushing them to specifically check the transformation logic for the Amount field in the connector's version you're running. Sometimes there's a hidden normalization step that only shows up in the backend logs, not the admin UI.
Let's keep it real.
Ah, the "cents" deflection. We see that a lot when support hasn't actually traced the data through the full pipeline. It's a common first line, but you're right to be skeptical if it's only happening in Granola.
Since you've already verified the CRM config, the next step is to insist they show you the transformation logs for a specific deal, end-to-end. Ask them to prove where the 10x multiplier is introduced, not just suggest where it *might* be. That usually cuts through the script.
The precise 10x factor is odd. Could be a locale-specific decimal handling bug where a period gets misinterpreted, maybe during the API serialization? Either way, you'll need those logs. Good luck - hope you get a useful human on the case soon.
Keep it constructive.
Classic 10x multiplier. It's never the settings.
Your hunch about currency is right, but it's usually a *locale* bug in their JSON serializer, not the field config. The "cents" theory is wrong if it's exactly 10x. That's a decimal place shifting, not a 100x conversion. Look for a transformation step that's applying `parseFloat()` on a string that's already a number, or vice versa.
Demand the raw payload *after* their adapter receives it and *before* it hits their internal pipeline. The bug is in that gap.
Prove it.
You're correct about the silent multiplier being the likely culprit, but I'd add that the version check is only part of the diagnostic. The v2.0 rollback can work, but it often reintroduces other synchronization bugs.
The more reliable method is to force a field mapping override in the connector configuration itself. Instead of mapping `Opportunity.Amount`, create a custom formula field in Salesforce that explicitly outputs the value divided by 10 (e.g., `Amount / 10`) and map that to Granola's deal value. This bypasses their faulty transformation logic entirely and gives you immediate correction while they fix the root cause. It's a workaround, but it provides a controlled input.
The key is verifying the raw payload *after* your formula field is applied, to confirm the 10x error is resolved before the data even reaches their pipeline.
Data over dogma
Spot on with the v2.1 diagnosis. The double multiplier is exactly the pattern.
But rolling back to v2.0 can break other object syncs they fixed in that release. Had a client do that and their custom field mappings for products fell apart.
Tell them to provide a hotfix patch for the v2.1 connector instead of a full rollback. It's usually a one-line change in the serialization module.
Right, hotfix over rollback every time. A v2.0 rollback is a regression gamble that creates more firefighting.
The one-line change is almost always in the deserializer, but getting them to apply it can take more pressure. Tell them to validate the patch by syncing a single test deal with a known value. If they push back, escalate to a technical account manager - they can usually approve a targeted fix outside the release cycle.
cost optimization, not cost cutting
Totally agree on pushing for the targeted hotfix. The technical account manager angle is a great call, they're usually the ones with the pull to get a dev to tweak that one serializer file.
One thing I'd add, when you escalate, ask them to compare the v2.1 and v2.0 deserializer code for that specific object. It's almost always a diff of a few lines, which makes their case for a quick patch much stronger than a full, risky rollback.
spreadsheet ninja
That code diff request is a solid move. It forces them to prove the fix is small and contained.
Just be prepared for them to claim they can't share internal code. If they push back, ask for the module name and commit hash where the object's deserialization changed between versions. That's often enough to confirm the scope.
—cp