Contents
Built-in guardrails
These protections apply automatically to every rule — they reduce risk, but they don't replace configuring a rule sensibly in the first place.
- New rules never backfill history
- Every rule records a baseline of everything that already exists the moment it's created. Only new activity after that point can ever trigger it — a rule can never fire on something that was already there.
- Duplicate-content checks
- Reply and post actions check for duplicate or substantially similar content before sending, and skip the action if it looks like a repeat — this is also a direct requirement of several platforms' own anti-spam policies.
- Per-contact cooldowns
- SocFlow tracks who's already been contacted by which rule and won't re-trigger the same action against the same contact, even after a cooldown window passes. This applies to follows and likes, not just DMs and replies.
- Opt-out enforcement
- If someone replies or mentions asking not to be contacted again ("stop messaging me", "unsubscribe", and similar phrasing), SocFlow detects it and permanently stops automating any further contact with that person from that account — honoring an opt-out request isn't optional under any platform's rules.
- Some combinations are blocked outright
- A handful of trigger/action combinations are flatly prohibited by a platform's own policy rather than merely risky — automated DMs on X, replying or following based on a keyword search alone on X and Mastodon, and non-opt-in likes/replies/follows on Bluesky. SocFlow won't let you build these, on any platform, regardless of how the rule is created.
- Managed X spend cap
- Connecting X through SocFlow's own app (no developer app of your own required) is metered against a safety cap — it protects SocFlow's cost exposure, not something you're billed for directly. Any single automation using SocFlow's app auto-pauses if its own usage crosses $5 in a day; if your organization's combined usage crosses $25 in a month, every automation using SocFlow's app pauses at once. Either way you get a notification naming the automation and reason, and can re-enable it any time — usually just narrowing an overly broad keyword fixes it. Accounts connected with your own X developer app are never subject to this.
- Automated-account disclosure
- Where a platform supports it, accounts driven by SocFlow can self-label as automated (e.g. Mastodon's bot flag, native automation disclosure on other platforms) — so people you interact with know they're talking to a bot.
- Descriptive, per-account identification
- Requests SocFlow makes on your behalf identify themselves distinctly per account rather than using a generic, unidentifiable client — several platforms (Reddit included) explicitly require this.
Guardrails reduce risk, they don't eliminate it
These protections catch the common failure modes, but they can't stop a rule that's simply configured too broadly — a keyword filter that's too generic, or a reply action turned on for a trigger that fires constantly. Read platform rules to respect and start narrow, especially on a new rule.