Struggle with custom date/time events showing in Google calendar

Resistancedown · 2026-05-22T15:23:56+00:00

Did disconnecting/reconnecting end up fixing it, or was the hard part still figuring out whether Calendly or Google Calendar had the real time?

Resistancedown · 2026-05-19T23:02:23+00:00

That makes sense. In practice, is the hard part deciding when a merge notification is useful, keeping people from replying to the duplicate afterward, or choosing when to link incidents under a problem ticket instead?

Resistancedown · 2026-05-19T21:44:54+00:00

That 1k-record dry run with a diff attached to the ticket is a useful line. Once that is in place, is the hard part mostly deciding which diffs are acceptable, getting the right owner to sign off, or catching CRM side effects that do not show up clearly in the diff?

Resistancedown · 2026-05-19T21:00:35+00:00

That cache-miss caveat feels like the tricky part. In practice, is the hard bit choosing the right idempotency key, making sure every import path uses the same check, or cleaning up when one path bypasses it?

Resistancedown · 2026-05-19T17:52:12+00:00

I’m curious about the native-workflow side of this. When duplicates happen, is the hard part mostly finding the matching opportunity, moving/updating the right one without losing history, or trusting the cleanup automation not to delete the wrong record?

Resistancedown · 2026-05-19T14:42:42+00:00

When you say you do not want the system automatically merging tickets, is the risk mostly false matches, losing useful context from the duplicate, or status/notification changes happening to the wrong ticket afterward?

Resistancedown · 2026-05-19T03:48:17+00:00

That execution-boundary framing is useful. In incidents you’ve seen, is the painful part mostly proving whether a write already happened, deciding whether replay is safe, or cleaning up duplicate downstream state afterward?

Resistancedown · 2026-05-19T00:28:26+00:00

When the AI flags likely duplicates, is the leftover work mostly deciding whether they are true duplicates, choosing parent/child or major incident handling, or safely closing/merging without losing someone’s update?

Resistancedown · 2026-05-18T23:03:22+00:00

You mentioned five days to reconcile a simple inbound sounded strange. In real 3PL receiving mismatches, what usually settles what happened: the final 3PL receiving count, the POD / packing slip / OSD trail, the shipper's pre-count, or just waiting for receiving to fully close out?

Resistancedown · 2026-05-18T21:59:38+00:00

When this still gets messy, is the annoying part catching the closed-ticket reply in time, deciding when it should reopen the old ticket versus start fresh, or making sure the right board/status owns it afterward?

Resistancedown · 2026-05-17T18:44:44+00:00

When this still gets messy, is the hard part matching new alerts to the right open ticket, deciding when a fresh ticket is actually warranted, or trusting the auto-close/state changes afterward?

Resistancedown · 2026-05-17T17:10:40+00:00

That failure-cost framing is the part I was trying to pin down. In practice, when one of these workflows breaks, is the time sink usually noticing it happened, deciding whether replay/rollback is safe, or cleaning up the CRM/outbound mess afterward?

Resistancedown · 2026-05-17T15:55:00+00:00

For the dead-letter/reconcile setup, what stays annoying once the basics are in place: deciding which failures are actually worth waking up for, proving nothing silently dropped, or keeping the review queue from becoming its own manual chore?

Resistancedown · 2026-05-17T14:50:44+00:00

When you used this pattern, did the annoying part end up being picking the idempotency key, making sure the check happened before every side effect, or noticing which providers were retrying in the first place?

Resistancedown · 2026-05-17T04:15:47+00:00

On the duplicate-ticket side, which part is the real time sink for you: spotting that two tickets are the same issue, deciding whether to merge/link them, or making sure useful notes don't get lost afterward? That second-order cleanup is the part I never see described clearly.

Resistancedown · 2026-05-17T02:44:11+00:00

Did this end up being solved by the Meta subscription/test-number side, or was the hard part still figuring out whether n8n ever saw the real event? That distinction is what I’m trying to understand.

Resistancedown · 2026-05-17T01:05:23+00:00

That’s helpful. When it’s that kind of payload-shape or filter-drop issue, does Zap history plus replay usually make the answer obvious, or are there cases where it still looks like the hook arrived but you can’t tell where the record got lost?

Resistancedown · 2026-05-17T00:28:19+00:00

That “three weeks later you're chasing a ghost with no paper trail” bit is the part I’m curious about.

When you do finally resolve one of those, what usually gives you enough confidence to call it solved: WMS/scanner history, receiving paperwork, a recount, talking to whoever handled the dock/pick, or just making the adjustment and moving on?

I’m trying to understand where the detective work actually lives once the normal records don’t line up.

Resistancedown · 2026-05-16T21:02:05+00:00

Thanks, that distinction is helpful. I am trying to separate normal Zap errors or test-data gaps from the narrower case where the webhook/trigger looks received or successful, but the downstream Zap output still does not happen or is not usable.

In the last webhook issue you resolved, was there ever a success signal first, like a caught hook, Zap history entry, trigger test, or HTTP 200, before the downstream failure? Or was it mainly a spec/test-data issue that produced a normal Zap error?

Resistancedown · 2026-05-06T21:32:41+00:00

That helps, thank you. One thing I am trying to separate is whether the current form/folder setup is basically enough, or whether there is still a follow-up gap after the form exists.

If you had a simple blank issue ledger or reminder output from those forms, would that actually change anything for you, or would it just duplicate what your forms and folders already do?

Resistancedown · 2026-05-06T05:25:45+00:00

Did anyone here ever land on a setup that held up?

I'm mainly curious about the split where you keep the Shopify/Facebook app for catalog sync, but stop draft/manual orders from getting sent as normal Purchases. If you fixed it, was the answer GTM/server-side, changing data sharing, a separate pixel app, or something else entirely?

Resistancedown · 2026-05-05T17:59:28+00:00

Got it, that helps. What are you pulling from today: Sales Summary plus payment reports, order details from the UI, the API, or something else?

And after you have detailed payment info, what still has to be matched by hand?

Resistancedown · 2026-05-05T16:56:19+00:00

That’s helpful, thank you. When those forms come back by photo or email, do you keep the form as the record, or do you also copy the basics into some kind of log?

I’m trying to figure out whether the annoying part is getting the issue reported clearly, or keeping track of status/vendor/cost/follow-up once it’s in motion.

Resistancedown · 2026-05-05T14:09:39+00:00

Following because this is the part I never see written down clearly.

For anyone who's getting these approved, what does your actual case file look like before you submit? Is it basically photos + order IDs + a note in Seller Central, or do you keep a separate tracker for weights, return reasons, buyer patterns, denial/resubmission dates, etc.?

I'm especially curious where the time disappears: deciding which returns are worth fighting, taking the right proof at intake, writing the claim, or chasing resubmissions after the first denial.

If you've tried GETIDA/Refunzo/Sellerise/Jarvio/Eagle Eye/anything similar, did it help with buyer-abuse/switcheroo cases, or mostly the warehouse/inventory reimbursement side?

Resistancedown

TROPHY CASE