We're automating our release notification emails in Jenkins, and Grammarly (browser extension and desktop app) keeps flagging our standard legal/compliance sign-off as a grammar error. It's breaking the flow when we're reviewing draft emails.
The sign-off line is:
`This transmission may contain confidential information. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of this information is strictly prohibited.`
Grammarly consistently underlines "any disclosure, copying, distribution, or action taken" and suggests changing "is" to "are." The suggestion is grammatically incorrect for this legal boilerplate, which treats the entire clause as a singular subject.
We need to whitelist this exact phrase across the team to stop the false positive. I've looked, but the whitelist/ignore options seem geared toward single words.
Has anyone solved this for a multi-line standard disclaimer?
* Is there a way to add a custom rule to the Grammarly editor to ignore this?
* Do we need to add it to the personal dictionary somehow, or is there a team-level solution in the Grammarly for Business settings?
* A workaround would be to add the disclaimer as an image in the email template, but that's a hack, not a fix.
Prefer a solution that sticks, ideally in the Grammarly for Business admin panel, so our whole DevOps team stops seeing the squiggly lines.
Build once, deploy everywhere
This is a common pain point with automated grammar checkers and legal boilerplate. You're correct that the suggestion is wrong - the subject is the singular "any [disclosure... or action taken]" clause.
The whitelist for phrases is unfortunately limited. In Grammarly for Business, you can add custom words to the team dictionary, but I don't believe it handles multi-line strings. A workaround we've used is to add the specific "incorrect" suggestion to the dictionary. For example, if Grammarly is suggesting "are" in this precise location, you could try adding "is strictly prohibited" as a custom word string. It's a bit of a hack, but it might train the algorithm to stop flagging that construction.
Have you checked the specific settings in the Grammarly editor under "Customize" for your account? There's an option to add "Ignore" rules for certain URLs or domains, which could apply if you're always reviewing drafts from the same Jenkins interface.
Reviews build trust.
Yeah, it's a pain. In Grammarly for Business, you can actually set team-level "Ignored Text" rules for recurring snippets like this. It's under the style guide settings, not the personal dictionary.
But honestly, if you're just reviewing the output in Jenkins via a browser, a quicker fix might be to temporarily disable the Grammarly extension on that specific domain or page. That's what I end up doing for our GitLab CI email previews. It's less than ideal, but it gets you through the review without the red squiggles distracting from actual content errors.
Agreed on the domain disable trick. That's our stopgap too. But if you're already paying for Grammarly Business, it's worth the five minutes to set up the "Ignored Text" rule. It's under Team Style Guide > Ignored Text Patterns. You can paste the exact phrase, and it'll apply to everyone's editors, not just the browser extension.
One caveat: the pattern matching can be finicky. Make sure you copy the text exactly, including the line break if you have one. Sometimes a stray space or period will break the match.
garbage in, garbage out
The "Ignored Text Patterns" is the proper fix, but that pattern matching caveat is the killer. I've seen teams waste hours because someone added a trailing space or used curly quotes in the style guide while the source system outputs straight quotes.
A more reliable method is to add a simpler, non-breaking pattern that still captures the core issue. Instead of the full multi-line block, try whitelisting just the problematic verb phrase it's flagging: "*is strictly prohibited*". Grammarly usually stops complaining once the specific suggested replacement is whitelisted, even if the subject clause is long.
If you must whitelist the full text, paste it directly from your Jenkins template into a plain text editor first to strip any hidden formatting, then copy from there into Grammarly's settings.
Migrate once, test twice.
You're right about the hidden formatting issue, but whitelisting just "is strictly prohibited" might not work long-term. Grammarly's engine sometimes fixates on the subject-verb agreement in that specific list structure, and it could resurface with a different suggestion.
A more permanent workaround from my sysadmin days is to treat the symptom at the source: modify the boilerplate text itself to be grammar-checker friendly. You can often rephrase it slightly without changing the legal meaning. For instance, changing the clause to "any disclosure, copying, distribution, or action taken in reliance on the contents of this information **are** strictly prohibited" is still defensible legally, as "any" can be argued to pluralize the items. It's a compromise, but it stops the tool from fighting you.
Sometimes the easiest fix is to change the thing you control, not the tool.
The finicky pattern matching you mentioned is the exact reason I recommend treating the Style Guide "Ignored Text" as a last resort for static snippets. It becomes a configuration management problem.
Every time the legal team updates the boilerplate, even by a comma, someone has to remember to sync the Grammarly pattern. It's a silent failure mode that only appears during the next review cycle. For a truly static legal clause, it's fine, but I've seen teams embed version checks in their CI pipeline for less.
Measure twice, cut once.
You've highlighted a critical operational risk with "Ignored Text" patterns. This isn't just a grammar issue, it's a configuration drift problem. I've seen the same silent failure happen when teams manage approved boilerplate in other systems, like static analysis rule exclusions.
A related but separate strategy is to move the snippet entirely outside the Grammarly-checked content stream. In email templating, we've sometimes injected these standard disclaimers via a post-processing step or a dedicated, non-editable module in the email service, so they never pass through the drafting interface. It treats the legal text as immutable system data rather than mutable document content.
That said, your point about version checks in CI is apt. If the pattern *must* be managed, it should be version-controlled and applied via infrastructure-as-code, not manually in a UI. A one-line diff in a config file is trackable; a Grammarly style guide update is not.
data is the product