Inline Editing: Spreadsheet-Speed Jira Cells
Double-click any cell in a Foundation Lens to edit it — status transitions, priorities, assignees, sprints, dates, custom fields. Every change syncs to Jira instantly via the Forge API. No context-switch, no tab-hopping.
What cells can I edit inline?
Foundation ships eight purpose-built inline editors, one for each common Jira field shape. You don't configure which editor appears — Foundation picks the right one based on the column's underlying field type, the same way Jira's own edit screen does. Double-clicking a cell (or pressing F2 with the cell focused) opens the appropriate editor inline, positioned over the cell itself.
The full matrix: Text editor — summary and text custom fields; Number input — story points, numeric custom fields, with increment arrows; Date picker — start date, due date, date custom fields, calendar popup with keyboard support; Status dropdown — reads the issue's current workflow step and lists only the valid transitions; Priority dropdown — the priorities your Jira instance defines; Assignee picker — typeahead over Jira users; Sprint dropdown — active and future sprints on the board; Labels editor — multi-value tag input with autocomplete against existing labels.
How do status transitions work?
Status cells don't just show a dropdown of every workflow state — they show the exact transitions your Jira workflow allows from the current state. When you open a status cell, Foundation calls Jira's transitions endpoint for that issue and lists the valid next steps. If the current step is “In Progress” and the workflow only permits moving to “Done” or “Blocked”, that's what you see. No invalid jumps, ever.
Picking a transition triggers Jira's full workflow machinery server-side: validators run, conditions are checked, post-functions execute, notifications fire. If a transition is rejected (a required field wasn't set, a validator blocked it), Foundation surfaces Jira's exact error message in a toast and the cell reverts. When a transition succeeds, the row animates and the updated status appears throughout Foundation within a couple of seconds via Forge product events. See the editing doc for the full flow.
How does the assignee picker work?
The assignee picker is a typeahead search against Jira's user directory. Click or tab into the Assignee cell, start typing, and the dropdown filters the user list by display name and username within a few dozen milliseconds. Pick a user with the mouse or press Enter to commit the highlighted result. The picker shows avatar, full name, and username for disambiguation when two users share a name.
Recently assigned users float to the top of the initial result list, so reassigning an issue to the same person you've been triaging all morning is one keystroke plus Enter. The picker supports unassigning (clear the field to “Unassigned”) and respects Jira's project-level “Assignable User” permission — users who cannot be assigned to the issue's project don't appear in results. The picker uses the same Atlassian Design System components as Jira's native assignee field, so it looks and behaves identically.
Can I bulk-edit multiple rows?
Yes. Shift-click or Cmd-click to select a range or set of rows, then open the Bulk Actions menu from the toolbar (or press B) to apply a single change across the selection — reassign all to one user, change status on a batch, set a common due date, add a label. Foundation queues the writes through Jira's REST API and shows a live progress bar; failed writes surface per-row with reason, so you can retry individually.
Keyboard shortcuts accelerate the same workflow: arrow keys move the active cell, Enter or F2 opens the editor, Tab moves to the next editable cell, Shift+Space selects the current row, Cmd+Shift+Arrow extends the selection. Power users can edit a whole row without touching the mouse: Tab through each cell, type or pick a value, Enter to commit. For very large batches, Bulk Actions hands off to Jira's native bulk-edit wizard so you inherit its validation and confirmation prompts.
How does inline editing compare to Structure's editing?
Structure by Tempo supports inline editing on core Jira fields and does so well — the category expected editing capability is table stakes here. The distinguishing differences are breadth and density. Foundation supports editing on more field types in the grid today (sprint picker, labels multi-editor, custom field shapes Structure marks read-only) and exposes five density modes so you can edit rows at sizes from 44 px down to 16 px — useful when you're scanning a portfolio for a specific value to change.
The other difference is platform. Foundation runs on Forge, Structure on Connect. Foundation's inline edits call Jira directly from the Forge runtime inside Atlassian's cloud — the round-trip is Atlassian-to-Atlassian. Structure's edits route through Tempo's Connect servers before hitting Jira. Both work; Foundation's path is shorter and has fewer trust boundaries. See Foundation vs. Structure for the full head-to-head.
What about conditional formatting?
Every Lens supports conditional formatting — rules that style cells or whole rows based on field values. Foundation's rule engine exposes 14 operators: equals, not equals, contains, starts with, ends with, greater than, less than, greater or equal, less or equal, is empty, is not empty, in list, not in list, and matches regex. Scope is per-rule: apply styling to the cell that matched (cell scope) or to the entire row (row scope).
Common patterns: color-code status cells by category (red for Blocked, amber for In Progress, green for Done); highlight overdue issues (Due Date less than today) at the row level; flag high-priority items that have been unassigned; emphasize issues where story points exceed a threshold. Rules stack in priority order and combine with AND / OR logic. See the formatting docs for the full rule-builder walkthrough.
What density modes does Foundation support?
Foundation offers five density modes so you can match the grid to the task. Comfortable (44 px row height) is the default — generous padding, full avatars, ideal for daily editing work. Cozy shrinks padding while keeping the full-size avatars. Standard matches Jira's native grid density. Compact drops row height further and switches avatars to initials. Micro (16 px row height) is for scanning — you can see 30+ rows without scrolling, with compact text, no avatars, and tight column spacing. All five modes support inline editing; the editors scale with the row height.
Toggle densities from the toolbar Density menu (or press D to cycle). Setting persists per Lens per user, so your planning Lens can live at Comfortable while your portfolio overview lives at Micro. Conditional formatting, column formatting, and inline editors all render correctly at every density — this is tested at all five levels for every release.
Frequently asked questions
Does inline editing respect Jira permissions?
Yes — every edit runs server-side through Jira's REST API as the current user, which means Jira's project permission scheme, issue security scheme, and field configuration all apply. If a user lacks Edit Issue on a given project, the cell opens but the save round-trips a 403 from Jira, the cell reverts, and a red toast explains the denial. If an admin has hidden a field from the edit screen, Foundation marks the cell read-only and the editor never opens. Foundation enforces this per-row in lenses that span multiple projects, so a user with mixed permissions only edits where they're allowed.
Can I undo an edit?
There's no Cmd+Z undo stack — once you press Enter or click outside the cell, the change is committed to Jira. To revert, make a second edit back to the previous value, or undo in Jira directly (which propagates back to Foundation through the same product-event path that backs every Jira-to-Foundation sync). For irreversible transitions — workflow steps that run post-functions like closing a sprint or notifying external tools — Foundation shows a confirmation prompt before the first write. A full undo stack is on the post-MVP roadmap; the tradeoff today is speed: no undo means no latency on the happy path.
What happens if an edit fails?
Foundation applies the edit optimistically in the grid (so you see it immediately), then waits for Jira to confirm. On success, the row animates a subtle green shimmer to acknowledge the write. On failure — permission denial, validation error, workflow-transition rule rejection, or network error — the cell reverts to its prior value within a few hundred milliseconds and a red toast surfaces Jira's exact error message. Nothing is silently dropped. If the error repeats, Foundation suggests the likely cause (missing permission, required field, transition validator) rather than showing raw JSON.
Can I edit custom fields?
Most of them, yes. Foundation detects custom field types at install and maps each one to the closest inline editor: text fields use the text editor, number fields use the number input, select/multi-select fields use a dropdown, user pickers use the assignee picker, date fields use the date picker, and labels/multi-value fields use the labels editor. Unsupported types — highly customized scripted fields, plugin-provided fields with non-standard serialization — are marked read-only with an explanatory tooltip. The field-type matrix is published in the docs; new types are added as we see them in the wild.
What about epics and initiatives?
Epics and initiative-level issue types (Theme, Initiative, Capability — whatever your Jira hierarchy calls them above Epic) are first-class in Foundation. You can inline-edit their summary, status, priority, assignee, dates, and custom fields just like any other issue type. The hierarchy itself is independent of Jira's native parent-link field — Foundation stores its own parent-child tree in Forge SQL, so you can put an Epic under a Theme in a Lens even if Jira's configuration doesn't allow that parent relationship natively. Epic-specific fields like Epic Name and Epic Color are supported where present.
Related
- What is a Lens?
- Sync Agents — JQL Insert and Child Extend
- Foundation vs. Structure — side-by-side comparison