Use Scenario Outlines when the intent is identical and only data varies—this keeps the feature file readable and ties all examples to the same AC. If different business rules surface, break them into separate scenarios so each AC maps to one behaviour and one test-report row.
Government guidance echoes this “one-rule-per-test” idea: U.S. web standards list discrete AC per function (“Site-Search Acceptance Criteria” | Standards.Digital.gov)

[https://standards.digital.gov/standards/site-search/%5C] and Canada’s GC Forms backlog links each accessibility rule to a distinct Gherkin test (“How we’re building GC Forms…” | Digital Canada) [https://digital.canada.ca/2023/02/16/how-were-building-gc-forms-our-4-accessible-approaches/%5C]. Saudi digital RFP scoring also weights criteria individually (Guideline of Digital Projects RFPs | DGA Saudi) [https://dga.gov.sa/sites/default/files/2022-10/Guideline%20of%20Digital%20Projects%20RFPs_1.pdf%5C].

Industry practice backs this: outlines reduce duplication and speed automation (“Reawakening Agile with OKRs?” | InfoQ) [https://www.infoq.com/articles/agile-okrs/%5C], and the Appinventors guide shows Given/When/Then plus checklist examples side-by-side (“Acceptance Criteria for User Stories in Agile…” | Appinventors) [https://appinventors.com/blog/acceptance-criteria/].
So—single behaviour → outline; different behaviours → scenarios. Your cucumber reports (and your stakeholders) will thank you.