How to manage Backlog in Kendis

The backlog is your collection's working view of everything it contains: every level of the hierarchy in one table, editable in place, with the connection to Jira or Azure DevOps kept live in the background.

Open it from the left navigation of any collection.

This guide is a complete reference. Read section 1 and 2 to get going, then use the rest as a lookup.

The screen is four horizontal bands. Knowing which band owns which job saves a lot of hunting.

If your Jira or Azure DevOps token has expired, a banner appears here telling you to update it. Until you do, nothing syncs and ALM-backed edits will fail.

Left to right:

Appears under the toolbar as soon as anything is narrowing the view: your search text, each filter condition, each column funnel. Every chip clears on its own, and Clear all resets the lot. If this bar is empty you are looking at the whole collection.

Row range ("Showing 1 to 50 of 812 items"), the page controls, Per page, and the freshness chip with its information icon.

I want to see my work. Pick your level in Start, then use the chevrons to open children. Search by key or words at any time.

I want to change something. Click the cell. Almost every column is editable in place, and the change reaches Jira or Azure DevOps in the same action.

I want to change many things. Tick the row checkboxes, and the bulk bar appears at the bottom.

I want to get work into this collection. Four ways, in increasing order of automation:

I want to know why something is on screen. Look at the tag next to its title, or hover it. Section 18 is the full list.

A backlog is a hierarchy, not a flat list. Start in the header chooses which level forms the top rows; everything below it becomes expandable children.

The list offers Top level plus each level your collection's hierarchy defines, named as your company names them.

Your choice is remembered per collection, so you land where you left off.

The Children column tells you how many children a row has before you open it, broken down by level.

Sometimes a row has children that are not members of this collection: they belong to the wider hierarchy but nothing here matches them. In that case a small funnel appears on the count, and the tooltip is explicit about the split, for example "Showing 4 of 11 children. The other 7 are not members here."

Click the funnel to peek at all of them. Peeked rows:

Click again to go back to members only.

Parent rows summarise their subtree rather than showing only their own values.

Everything you can show, in the order the picker lists it. Which ones exist depends on your connection and your collection's configuration.

Columns in the toolbar opens the picker.

Drag the right edge of any column header. The width is yours and is remembered.

Freezing pins the leading columns so they stay in view while everything else scrolls sideways. Useful when you have twenty columns and still need to see the key and title.

Your column set, order, widths and frozen boundary are saved per collection, per user, so your view is yours and does not disturb anyone else.

Click a sortable column header to sort by it, click again to reverse. Custom fields sort as well as built-in columns.

The active sort appears as a chip in the toolbar, and the small close icon on that chip resets it.

Backlogs are ranked, so the grid also supports a deliberate hand-made order.

Grab a row by its drag grip and drop it on a sibling to move it there. Two rules apply:

An item that is on screen only because it matches a membership rule has no position of its own to save. Pin it to the collection first, and then it can be reordered.

The footer shows the range and the total. Page size options are 20, 50, 100, 200 and 500. Paging applies to the top-level rows; children always load under their own parent.

Focus / drill in on a row's menu narrows the whole grid to that row's subtree. A breadcrumb appears above the grid naming what you are focused on, and Back steps out.

Use it to work one epic at a time without losing the rest of the collection.

Each row saves on its own and shows a brief saving state. For an item connected to Jira or Azure DevOps, the same change is pushed to that tool in the same action. There is no second "push" step to remember.

If the push fails, the row keeps a sync error tag. Hover it for the tool's own message, which is usually a required field or a permission on that side. Fix the cause there, then edit the field again to retry. If a field cannot be saved, the grid says which one rather than failing quietly.

The 3-dots menu at the end of any row:

These are two different things, and the dialog is careful about the difference.

Before either happens, Kendis checks the impact and tells you what it found:

Deleting cannot be undone, and the dialog says so.

Tick the checkbox on any rows and the bulk bar appears at the bottom, showing how many are selected.

Every action confirms first, naming the exact change and how many items it touches.

How bulk behaves:

Add item > Create new, or Create child on a row.

Type a key, press Enter, and Kendis resolves it:

This is deliberate: a hierarchy that is wrong is far more expensive to unpick later than a rejected keystroke now.

Add item > Add existing, or Add existing child on a row.

Search Kendis and the connected tool together, by key or by free text. Azure DevOps also accepts a work item ID.

An item may only be added at a level its type is mapped to. If you search up an item whose type belongs elsewhere, the row does not silently accept it:

The footer keeps the two groups separate, for example "6 selected, 2 at their own level", so you always know what is about to happen.

Selections are added level by level, and the dialog reports anything that could not be added rather than failing the whole batch.

The search box matches keys and titles across the whole hierarchy, not only the rows currently loaded. Matching items keep their parents visible so you can see where they sit.

Search is not available in the archived view.

Every filterable column header carries a funnel for quick single-column narrowing.

Column filters combine with the drawer's conditions, and each appears as its own chip on the applied-filter bar.

Filters in the toolbar. The badge is how many conditions are active.

Fields you can filter on: Issue type, Priority, Project, Status, Assignee, Quarter, Time period, PI Boards, Estimate (SP), the three % Completion fields, Key, Title, Teams, Sprints, Solution Boards, Batches, Objectives, plus your custom fields.

Operators: is any of, is none of, is, is not, is empty, is not empty, contains, does not contain, greater than, greater than or equal, less than, less than or equal, equals, between, is under, is not under.

Building a filter:

From the drawer:

Browse library in the drawer lists your saved Kendis filters together with your Jira and Azure DevOps queries. Search by name, see how many rules each carries, and select one to apply it.

Tick some rows and choose Create filter on the bulk bar. This saves exactly those items as a reusable saved filter, with a name and an optional private flag. Useful for a candidate list you want to come back to without rebuilding conditions.

Everything narrowing the view, shown as chips: the search text, each condition, each column funnel. Each chip clears alone, and Clear all resets everything at once.

Group in the toolbar. The list is searchable and organised into categories:

Grouping by a filter or query is the fastest way to answer "what did this query actually bring in?".

Items with no value for the dimension get their own bucket, named for what is missing: No parent, No PI board, No sprint, No team, Items without Filter.

Multi nests a second dimension inside the first, for example PI Boards, then Status.

A grouping you use often can be saved as a preset, named, and kept Private or Shared. Presets can be updated in place or deleted. You can only change presets you own.

This is how a collection stays populated without anyone adding items by hand.

Open Settings > Manage Filters, or Add item > Add Jira filter (JQL) / Add Azure DevOps query to go straight to the add step.

The dialog lists everything currently feeding this collection, with an active count, and an Add filter menu.

Expand any row for its details:

Per-row actions:

Every add path runs the query first and shows the count before anything is saved. The Save button stays disabled until that succeeds, and it carries the number with it, for example Save · 128 items.

Editing the query or changing the level clears the result, so the number on the button always matches what will actually sync. This is the whole point: you never add a filter blind and discover its blast radius afterwards.

Add filter by hierarchy is the same thing with the order reversed: pick the level first, then the filter.

Edit JQL reopens this dialog for an existing hand-written filter. Re-run the query to see what it brings in now, then save over the existing filter. You no longer have to remove and re-add a filter to change one clause.

A resync asks whose access fetches the items:

It defaults to the identity the filter last synced with, so the ordinary case is one click.

While it runs you get a live progress screen with elapsed time and two choices: keep watching, or Run in background and carry on working. When it finishes, the screen reports how long it took, and Done closes it and reloads the backlog with the new items. If the sync reports a problem, the screen says so rather than quietly ending.

A toggle at the top of the dialog decides how the background sync authenticates:

Pick On when a collection must keep syncing regardless of who set a filter up.

A filter feeds the level you choose. Child items are pulled in automatically when their parent syncs, so you do not need a filter per level to get a full hierarchy.

A filter is a snapshot of a question asked once and re-run. A rule is a standing definition of what belongs here.

Rules in the toolbar. Editing rules is an admin job; everyone can see them.

A rule is a hierarchy level plus conditions items must match, for example "every item at Feature level with the label payments". Anything matching becomes a member, including items created next month. Change the rule and the matching rows change with it. No re-adding, no re-importing.

Rules are listed by level, with a live count of how many items each one matches.

Each rule chooses its reach:

Rules using the whole hierarchy carry a Whole hierarchy badge so the difference is visible at a glance.

Strict rules is a collection-wide switch: at levels that have rules, show only rule matches.

Members that were added by hand and do not match are hidden, not removed, so turning strict off brings them all back. Levels with no rules are unaffected.

Use it when a collection is meant to be entirely defined by its rules and you want to see any drift.

"Remove from this collection" on a rule-matched row does not delete anything. It records an exception, so that rule stops matching that item.

The drawer keeps a Removed from this collection list of every exception, searchable, with Restore on each one. Nothing is lost, and a mistaken removal is a single click to undo.

Generate from queries turns this collection's Jira and Azure DevOps saved queries into membership rules, so a query you already trust becomes a living definition.

The dialog analyses each query first and tells you what it will do:

Convert all processes everything convertible in one go.

Rules depend on your company's shared item structure being switched on. If it is not, the drawer says plainly that rules are saved but not active yet, and that the backlog is still showing only items added by hand. Your Kendis administrator or support can enable it.

The chip in the footer reads Synced 12m ago, or Not synced yet.

What it measures: the oldest successful sync across the collections that share this hierarchy. It is deliberately the oldest, not the newest, so the chip never flatters the data. The information icon next to it explains this in place.

Other things the chip tells you:

Auto-sync speed. Click the chip to change it:

Background Auto Sync keeps the collection fresh with nobody pressing anything, and it covers items that were added by hand as well as items a filter brought in.

When a sync notices that an item no longer belongs, it flags the item instead of deleting it, because removing someone's work is a person's decision, not a background job's. Clean-up in the toolbar lists everything flagged, with columns for the item, its level, why it was flagged, how long it has been flagged, and its children.

Both are shown on the row itself as row tags too.

Check now re-runs every saved query of this collection with your credentials and flags what no longer matches. A failing query flags nothing, which is the safe direction.

The drawer reports the outcome: how many items each query returned, how many were tagged, how many are gone, and how many queries failed if any. It also shows when the last automatic check ran.

A check that would do something drastic is held rather than applied. The hold triggers when a query returns nothing at all, or when it would drop more than half of its items, because both usually mean a broken query or an outage rather than genuinely removed work.

Held checks say so, and name the query.

Select flagged items and choose:

Also remove their descendants extends the removal down the tree, and is explicit about what survives: children that match a filter or rule at their own level, were added by a person, or have another parent in this collection stay. Only children that were here purely because of the removed parent leave with it.

The confirmation names the exact total, including descendants.

Very long lists are truncated to keep the drawer usable; deal with some and the rest appear.

Remove automatically on sync is an admin-only setting. With it on, items a saved query no longer returns leave the collection during sync, still behind the same safety hold described above.

Leave it off if you want a person to see every removal first.

A collection is not a folder you drag things into. An item can be present for several different reasons, and the small tag next to its title tells you which. Hover any tag for the same explanation in place.

Orange. The item is still a full member until you decide.

Both are handled in the Clean-up drawer.

Amber and red. These are not about membership. They say the item and its counterpart in the connected tool disagree.

A sync error is nearly always a required field or a permission on the tool's side, so the message on the tag is the fastest way in.

"I see a Feature I did not add, tagged via rule." A membership rule at Feature level matches it. Open Rules to see which one. If it should not be here, remove it and the exception is recorded; the rule keeps working for everything else.

"A parent is greyed out and tagged context." A filter matched its children, not it. Kendis pulled the parent in so the hierarchy is not full of orphans. Its other children are not members unless they match something themselves.

"An item is tagged left filter but still here." The query stopped returning it. Nothing has been removed. Open Clean-up and decide: keep it as a member, or remove it.

"An item shows not in Jira." It was deleted in the connected tool. Kendis will not delete work behind your back, so it flags it instead. Delete it here when you are sure.

The Quarter / PI column carries two different things, separated by a divider.

The fiscal period the item is planned for, taken from the fiscal calendar in effect for this collection. See the Fiscal Year guide.

Click the chip to pick a period. The picker offers Years, Half-years and Quarters, with real date ranges, and a Now shortcut for the period containing today. Clear period removes it.

Setting a period also syncs the item's start and end dates to that period's span. Adjusting the dates inside the range afterwards is fine; the period stays. Clearing the period leaves the dates alone.

Which PI boards the item belongs to. Each chip opens its board. + period and the PI picker add more.

The picker searches all PI boards, not just this collection's, and it includes future PI placeholders, marked Future, which have no board behind them yet.

Tagging an item to a future PI placeholder is how next PI's scope builds up during the current PI, instead of being reconstructed in a planning workshop.

When the board for that PI is finally created through the wizard, everything tagged to the placeholder is carried onto the new board automatically. Nothing to re-select, nothing to confirm afterwards.

See the PI Roadmap guide.

The bulk bar sets the quarter or adds a PI board across a selection, which is the practical way to scope a PI in one sitting.

Settings > View Archived switches the grid into archived mode, marked with an amber bar.

Archive from the bulk bar in the normal view. Archiving moves items out of the backlog; nothing is deleted and you can restore at any time.

The download icon in the toolbar.

The export takes the current view: your search, your filters and your sort, across all pages, with the columns as shown on screen. Shape the view first, then export.

While it collects rows it shows a running count.

The cap is 5,000 rows. If you hit it, the export still downloads and tells you it was capped, so you can narrow the filters and take a complete file. Child collection goes six levels deep.

Flow moves work between collections with an explicit hand-off. It has its own guide: Collection Flow. What lives in the backlog:

Flow grouping and filtering apply only while the flow view is on, and take over from the backlog's own grouping so the two can never disagree.

Learn in the backlog header opens a guided tour of everything in this guide, in chapters: the grid, getting work in, why an item is here, finding and focusing, Flow, and the PI Roadmap connection.