Activity Logs in Elements Copy & Sync: Full visibility into your work item cloning and syncs

TL;DR Elements Copy & Sync has introduced Activity Logs, a redesigned logging system split into three areas: Execution Logs (every work item creation and cloning, including configuration and Jira-side errors, now with the triggering user visible), Synchronization Logs (proactive detection of sync errors between linked work items, exclusive to the Advanced edition), and Configuration Logs (a complete history of recipe and settings changes). Execution and Configuration Logs ship for every customer; Synchronization Logs are an Advanced-only capability. The combined result: admins spot failed clones and broken syncs immediately instead of through user complaints, get clear attribution on every action, and can self-serve most troubleshooting instead of opening a support ticket.

The problem with silent failures

Cloning work items, and keeping them linked and synchronized across projects, teams, or Jira instances, is some of the most valuable work Elements Copy & Sync does, and some of the quietest. Recipes run in the background, work item by work item, field by field, comment by comment, without drawing attention to themselves. That’s exactly the point, until one of them stops working correctly.

Two kinds of failures can slip through unnoticed. A recipe can fail outright when trying to clone a Jira work item, a misconfigured target project, a missing issue type, a Jira-side validation error, and if nobody’s watching the logs, that failed copy simply never happens. Separately, a sync between two already-linked work items can quietly break: a field stops updating, a comment never makes it across, an attachment goes missing. Either way, there’s historically been no signal until an end user flags that something looks wrong. By then, the admin is starting an investigation from behind.

Activity Logs was built to close that gap: a single logging experience covering work item copy attempts, synchronization health, and configuration history, so admins are never the last to know.

Where the current logs fall short

Before this release, Elements Copy & Sync’s logging only covered one thing: creation or copy of work items. Even there, a failed clone attempt was recorded, but without knowing which user triggered it, admins were often left guessing whose recipe, whose action, or whose workflow transition caused the error. On top of that, two whole areas were left completely unmonitored:

• Sync health. Nothing gets recorded when a mapped field, comment or attachment fails to sync between two linked work items. The failure is invisible until its effects surface elsewhere.
• Change history. Instances with several admins have no way to see who modified a recipe or a global setting, or when, a real obstacle for both day-to-day troubleshooting and formal governance requirements.

These gaps came up again and again in conversations with teams running Elements Copy & Sync across multiple projects and instances, which is what shaped the design of Activity Logs.

Inside Activity Logs: three tabs, one place to look

Activity Logs replaces the previous logging page in the app’s administration area and splits it into three dedicated tabs.

Execution Logs: creation of subtasks and cloning attempts

Execution Logs is the renamed, upgraded version of the existing log. It still records every attempt to create or clone a Jira work item, regardless of how it was set off:

• A manual action
• A workflow post-function
• A Clone & Move recipe
• A workflow status transition (triggering a workflow sync)
• A bulk copy operation
• A call to the REST API

Each entry includes the date, whether it succeeded or failed, the recipe involved, how it was triggered, the source work item, and a message describing the outcome. That message covers cloning problems specifically recipe configuration issues like a missing project or issue type in the recipe’s target, an issue type that doesn’t exist in the target project, more than one project or issue type specified in the target, or a rate limit being hit, as well as Jira-side validation errors, such as a mandatory field missing on the work item being created.

Two things are new in this tab:

• A column showing who triggered the action, so a failed clone attempt can be traced back to the recipe run and the user (or trigger) behind it.
• Broader filtering, so results can be narrowed by recipe, user, or work item rather than scanning the full list.

Synchronization Logs: catching sync errors as they happen (Advanced edition)

This is the core addition. In larger environments running many sync recipes across projects and instances, a sync that quietly breaks can cause real data drift before anyone notices. Synchronization Logs exists to flag these errors and warnings as they occur, rather than after the fact.

Instead of one row per event, entries are grouped by work item association (for instance, “TS-1 is blocked by TS-2”) across a rolling 24-hour window. Additional errors on that same association accumulate in the same entry; once the window closes, the next error starts a fresh one.

Collapsed, each line shows:

• When the last error occurred
• Which recipe was involved
• The source and target work items
• The link type connecting them
• How many errors were logged

Filters let you narrow this view by date range, recipe, source or target work item, and link type, so a specific problem association can be found directly rather than scrolled to.

Configuration Logs: a record of every change

The third tab tracks every modification made to recipes and global settings, along with who made it and when. For instances managed by more than one admin, or subject to compliance requirements around configuration control, this fills a gap that previously had no answer.

All three tabs share the same 90-day retention window and a consistent filtering experience.

Read more about Activity logs

Standard vs. Advanced: feature availability

Execution Logs and Configuration Logs, user attribution and expanded filters included, are part of every plan.

Synchronization Logs are reserved for the Advanced edition.

What this changes for admins

• Errors surface immediately, instead of arriving as a user complaint days or weeks later.
• Diagnosis becomes precise, whether it’s a failed clone or a broken sync, admins can see exactly what happened and where.
• Every action has an owner, across both execution and configuration events.
• Governance gets easier to demonstrate, with a full trail spanning execution, sync, and configuration.
• Most issues can be resolved without support, directly from the admin console.

Who this is built for

• Jira admins responsible for Elements Copy & Sync configuration get precise diagnostics, a full audit trail, and fewer incoming tickets.
• Project and program managers depending on cross-team or cross-instance sync gain confidence it’s working, or an early flag when it isn’t.
• Support teams managing support-to-development escalations benefit from a more dependable sync layer and faster root-cause identification.

For anyone not yet using Elements Copy & Sync but working with cross-team synchronization or work item creation at scale, Activity Logs is a good reason to take a closer look, it’s built to give admins confidence in what’s running, and the means to act quickly when something isn’t.

Try Elements Copy & Sync for free

Frequently Asked Questions

Are Activity Logs available on the Standard edition?

Execution Logs and Configuration Logs are available on both Standard and Advanced editions. Synchronization Logs are exclusive to Advanced.

How long is log data kept?

Execution, Synchronization, and Configuration Logs are all retained for 90 days.

Can admins see who performed a given action?

Yes. Execution Logs now include a column identifying the user who triggered each work item creation or cloning.

What kind of cloning errors does Execution Logs report?

It covers recipe configuration issues, such as a missing project or work item type in the recipe’s target, a work item type not available in the target project, more than one project or work item type specified, or a rate limit being reached as well as Jira-side validation errors, like a mandatory field missing on the work item being created.

What types of sync errors does Synchronization Logs catch?

It reports unsynced mapped fields, unsynced comments and unsynced attachments between linked work items, each with a plain-language explanation.

Does Configuration Logs record who changed a recipe?

Yes. It logs every change made to recipes and global settings along with who made it and when, providing a complete change history for governance and troubleshooting.

Can log data be exported?

Not yet.