Raley Intake Forms VS Jira cloud forms and Jira issue collector
Raley Intake Forms gives you full-power, externally shareable Jira intake forms — without the limits of native Jira Forms or the legacy Issue Collector.”
Features at a glance
Unlimited forms, not limited by Jira screens
Native forms and Issue Collector are constrained by Jira’s field/screen model; Intake Forms lets you create as many tailored intake experiences as you need.Reusable form UX across web, intranet, and Confluence
Issue Collector embeds a small Jira feedback panel; Intake Forms delivers the same full form anywhere you publish it.Cleaner experience for non-Jira users
You explicitly hide Jira complexity (issue types, field names, required Jira context), which reduces drop-off and training.Better fit for true “intake portal” patterns
Your forms can behave like a branded request portal without needing JSM portals or licenses for every requester.Works equally well for Jira Software and JSM
Native Jira forms’ feature set differs by product and plan; Intake Forms gives one consistent capability set everywhere.
This table compares forms capabilities of Jira/JSM Cloud and Raley Intake Forms.
Capability | Jira Cloud Forms (native) | Jira Issue Collector | Raley Intake Forms |
|---|---|---|---|
Conditional logic / dynamic behavior (show/hide, dependent fields, defaults) | No conditional logic in Jira Software / Business projects; limited roadmap here. | No. | Yes — built-in conditional fields, behaviors, defaults. |
Multiple languages / localized forms | No. | No. | Yes — serve the form in the user’s language. |
Different forms per issue type | Forms are project-scoped; not truly separated per issue type. | Yes (via separate collectors/screens). | Yes — create unlimited forms per project & issue type. |
Layout control (sections, columns, rich layout) | Limited layouts. | No (uses Jira create screen layout) | Yes — custom layouts per form. |
Multiple form variants per project/issue type | No. | No. | Yes — different layouts/logic per audience. |
Custom validation rules (regex, required-if, etc.) | Basic required fields only. | No. | Yes — advanced validation. |
Publish externally (share via link / embed anywhere) | Rolling out, but still constrained. | Yes (embed snippet), but basic and tied to Jira create screen. | Yes — embed on any website or Confluence, with full form UX. |
Anonymous submissions + attachments | Anonymous sharing has limits; attachments can’t be uploaded anonymously. | Attachments support is limited and historically brittle. | Yes — collect full request data (including files) without needing Jira accounts. |
Works with standard and custom Jira fields | Only Jira fields; you must create fields first. | Only fields on the create screen. | Yes — first-class support for standard + custom fields with mapping. |
Hide Jira complexity from requesters | Partially (still “Jira-ish”). | No (looks/feels like Jira mini create). | Yes — clean intake UI, Jira stays behind the scenes. |
Track request source / which form created the issue | Not clearly exposed. | Not clearly exposed. | Yes — easy to see which form/location created the ticket. |
Form designer UX | Basic designer in Jira UI. | No designer; admin copies JS snippet. | Yes — WYSIWYG form builder. |
Branding / CSS theming | Very limited. | Limited; requires custom JS/CSS work. | Yes — tailor-made CSS & styling. |
Support / feature openness | Product support via Atlassian. | Product support via Atlassian. | Yes — responsive support & fast feature iteration. |
Works really great with our Raley Emails Notifications app!