New discussion topics in Atlassian Community

Automating Zephyr Scale Migrations Between Jira Data Center Instances: An Open-Source Key Remapping

Michael Salvio — Wed, 08 Apr 2026 23:07:07 GMT

Migrating Zephyr Scale Between Jira Data Center Instances: An Open-Source Key Remapping Tool

TL;DR: The standard Zephyr Scale export/import process reassigns new keys to everything, silently breaking all cross-references between test cases, test runs, and test plans. I couldn’t find a tool that solved this, so I built one. It uses content-based signature matching to remap keys automatically across all three entity types—preserving your test data relationships without manual intervention. The code is open source, GitHub.

Background

I recently needed to migrate Zephyr Scale test data from one Jira Data Center instance to another as part of a larger consolidation effort—and this is going to be a continual process as we ingest a large number of other Jira Data Center instances into ours.

The standard export/import process works on the surface, but it reassigns new IDs and keys to everything. Test cases that were PROJ-T123 become TARGET-T456, and all the references in test runs and test plans silently break. You end up with imported data that looks complete but is internally incoherent.

I couldn’t find an existing tool that handled this remapping automatically, so I wrote one. This post explains the approach and shares the code.

What Breaks During Migration

When you export and import Zephyr Scale data between instances, four things go wrong:

Test cases get new keys in the target instance
Test runs reference the old test case keys, which no longer exist
Test plans reference both old test case and test run keys
Folder structures do not transfer automatically

The result is imported data that appears complete but has broken relationships throughout. Fixing this manually at scale—matching hundreds of old keys to new ones across test runs and plans—is the kind of work that takes days and is nearly impossible to do without errors.

The Approach: Content-Based Signature Matching

The core insight is this: when you import test cases, the keys change but the content stays the same. So if you can match entities by their content rather than their keys, you can build a reliable mapping between old and new—and use that mapping to fix all the downstream references.

How the Matching Works

After importing test cases to the target, the tool:

Loads the original source export file
Queries the target instance to get the newly imported test cases
Builds a content-based signature for each test case on both sides
Matches source signatures to target signatures to create a key mapping file

Test cases are matched using a combination of name (normalized), description or objective (normalized), and the first two test script steps. Test runs are matched using name, description, environment, version, and number of test items. This approach is robust as long as test case names and descriptions are reasonably unique within a project—which is true in the vast majority of real-world projects.

Before You Run the Tool

The tool handles data migration and key remapping, but it expects the structural elements to already be in place in the target instance. Before running, you’ll need to:

Create the target project in Jira
Recreate the folder hierarchy in Zephyr Scale (the tool preserves folder assignments, but the folders must exist)
Set up any custom fields used by your test cases
Configure environments, versions, and other Zephyr Scale settings to match your source

All operations on the source instance are read-only (GET requests only), so there’s no risk of modifying your source data during the migration.

The Migration Process

The migration runs in three sequential phases, each building on the key mapping produced by the previous one.

Phase 1: Test Cases

Export test cases from the source instance
Clean the data (remove IDs, timestamps, and fields that cause import conflicts)
Import cleaned test cases to the target instance
Query both source export and target instance, match by content signature, build key mapping file

Phase 2: Test Runs

Export test runs from the source instance
Replace old test case key references with new keys using the Phase 1 mapping
Clean and import test runs to the target instance
Query both source and target, match by content, build test run key mapping file

Phase 3: Test Plans

Export test plans from the source instance
Replace both test case and test run key references using both mapping files
Import test plans to the target instance

Each phase is self-contained—if something goes wrong, you can re-run that phase without starting over from the beginning.

Real-World Results

On our first migration run with the tool:

Metric	Manual Approach	With Tool
Key remapping	Manual spreadsheet matching	Fully automated
Reference integrity	Best-effort, error-prone	Validated programmatically
Source instance risk	Possible accidental writes	Read-only, zero risk
Repeatability	Starts from scratch each time	Reusable across all ingestions
Time for remapping phase	Days of manual work	Minutes

Because this is a continual effort—we’re ingesting multiple Jira Data Center instances over time—having a repeatable, automated process is essential. Running this manually even once would be painful; running it a dozen times would be untenable.

Getting Started

The tool is open source and available at GitHub.

Requirements

Python 3.6+
requests library
Personal Access Tokens (PATs) for both Jira instances
Target project created with Zephyr Scale structure in place (folders, custom fields, environments, versions)

Configuration

Configuration files go in the config/ directory:

config/source_base_url.txt

config/source_pat.txt

config/source_proj_key.txt

config/target_base_url.txt

config/target_pat.txt

config/target_proj_key.txt

Running the Migration

python 0_run_zephyr_migration_orchestrator_v2.py

The orchestrator walks you through the three phases in sequence, generating mapping files between each phase that are used as input for the next.

Things to Know Before You Run It

A few important considerations to set expectations:

You must manually recreate the Zephyr Scale folder structure, custom fields, environments, and versions in the target before running—the tool handles data and key remapping, not structural setup
Content-based matching assumes test case names and descriptions are reasonably unique within a project. If you have many identically-named test cases with identical descriptions and steps, matches may be ambiguous
Attachments are not currently handled and would need to be migrated separately
Designed for Data Center; Cloud API endpoints differ slightly and would require modification

For most real-world projects these constraints are non-issues. If your project has significant numbers of duplicate test case names, you’ll want to review the mapping file before proceeding to the next phase.

Lessons Learned

The Key Insight: Import First, Map Second

The temptation when facing a key remapping problem is to try to pre-compute everything before importing. That doesn’t work well with Zephyr Scale because you don’t know the new keys until after the import. Flipping the order—import first, then build the mapping by comparing what you sent with what arrived—makes the problem tractable.

Content Signatures Are More Reliable Than You’d Expect

I was initially skeptical that matching by content would be robust enough for production use. In practice, test cases with meaningful names and descriptions match reliably. The first two script steps add enough signal that even test cases with similar names usually resolve correctly.

Phase Isolation Saves Debugging Time

Structuring the migration as three independent phases—each producing a mapping file—means you can inspect the mapping after each phase before committing to the next. Catching a matching issue after Phase 1 is far less painful than discovering it after you’ve already imported test plans.

Built with AI: A Claude Code Story

Like my CMJ migration toolkit, this tool was built collaboratively with Claude Code, Anthropic’s AI-powered CLI assistant. The content-signature matching approach emerged through iterative discussion—I described the key remapping problem, and working through the solution together surfaced the “import first, match second” insight that makes it work.

The experience reinforced the same lesson: AI amplifies domain expertise rather than replacing it. I knew the Zephyr Scale data model and what a valid migration needed to look like; Claude Code helped me build the implementation quickly and think through edge cases I would have hit later in testing.

None of This Works Without the Right Customer

Tools like this don’t get built—or validated—in a vacuum. A critical ingredient in making this tool production-ready was having a customer who was genuinely invested in getting it right.

Ryan Stroup dedicated real time and attention to this effort: testing the migration pipeline against his projects’ actual data, validating that the content-based matching was producing correct key mappings, and confirming that every requirement of his projects was met before sign-off. That kind of engaged partnership is what separates a tool that works in theory from one you can trust on real test data.

The matched-key validation step in particular benefited enormously from Ryan’s hands-on testing—edge cases in test case naming and structure only surface when you run against production data with someone who knows what correct looks like. If you’re planning to use this tool, I’d encourage the same model: a willing, thorough collaborator on the customer side is just as important as the automation itself.

One Challenge Left to Solve

One area I didn’t have time to tackle is automating the recreation of the Zephyr Scale project structure itself—folders, custom fields, environments, and versions—from the source instance to the target. Right now that’s a manual prerequisite step, which works fine for a single migration but adds friction when you’re ingesting many instances repeatedly.

In theory this should be achievable via the Zephyr Scale REST API: query the source structure, then recreate it in the target before the data migration begins. In practice I haven’t validated how reliably the API supports all the edge cases involved, so I left it as a manual step rather than ship something half-baked.

If you’ve already solved this or want to collaborate on it, I’d love to hear from you in the comments. It’s on my list to revisit.

Conclusion

Zephyr Scale migrations between Data Center instances are deceptively tricky—the standard export/import gets the data across, but the broken key references leave you with test data that looks complete and isn’t. Content-based signature matching solves the remapping problem without requiring any manual key tracking.

If you’re facing a similar consolidation effort—especially a repeated one—I hope this tool saves you the days of manual work it would otherwise take.

The code is on GitHub. Issues and PRs are welcome.

Questions or feedback? Drop a comment below. I’d especially like to hear from anyone who’s tackled this problem a different way, or who has run into matching edge cases I haven’t encountered yet.

Automating CMJ Migrations at Scale: An Open-Source Python Toolkit

Michael Salvio — Wed, 08 Apr 2026 22:54:24 GMT

Automating CMJ Migrations at Scale: An Open-Source Python Toolkit

TL;DR: After managing multiple large-scale Jira migrations using Configuration Manager for Jira (CMJ), I built a Python toolkit that automates the tedious parts—mapping validation, conflict detection, template generation, and post-migration cleanup. The code is open source on GitHub. This article shares the approach and lessons learned.

The Problem: CMJ Migrations at Scale

If you’ve ever done a Jira Data Center migration using CMJ, you know the pain:

Hundreds of objects to map: Statuses, custom fields, issue types, resolutions, link types—each needs a decision
Customer coordination: Someone has to review spreadsheets and make mapping decisions
Human error: Typos, copy-paste mistakes, and inconsistent naming can silently break a migration
Post-migration cleanup: CMJ creates objects that need to be deleted, but which ones are safe to remove?
No audit trail: What got mapped where? What was created vs. deleted?

For a single small project, this is manageable. For enterprise migrations with thousands of objects across multiple projects, it becomes a full-time job.

The Solution: An 11-Step Automated Pipeline

I built a Python toolkit that wraps around CMJ to automate the repetitive work while keeping humans in the loop for decisions that matter.

The Pipeline at a Glance

Phase	Steps	What Happens
Pre-Deployment	1–6	Convert data, process mappings, validate, generate CMJ templates
Customer Review	Between 3–4	Customer reviews and approves mapping decisions
CMJ Deployment	Manual	Import templates, deploy snapshot
Post-Deployment	7–11	Generate cleanup scripts, validate before/after deletion

Key Automation Features

The toolkit handles four categories of work that are tedious and error-prone when done manually:

Intelligent Matching

The toolkit automatically matches source objects to target objects using:

Exact name matching
Fuzzy matching with confidence scores (e.g., “In Progress” → “InProgress” at 92%)
Type validation for custom fields (Text → Text, not Text → Number)

Match Results:

EXACT_MATCH: 234 objects (auto-mapped)

FUZZY_MATCH: 45 objects (suggested, needs review)

NO_MATCH: 28 objects (will be created)

Conflict Detection

Multiple source objects mapping to the same target? The toolkit catches it before it reaches CMJ:

CONFLICTS DETECTED:

Target 'Approved' ← Sources: ['Approved', 'APPROVED', 'approved']

Target 'In Progress' ← Sources: ['In Progress', 'InProgress']

Customer Review Validation

Before generating CMJ templates, the toolkit validates the customer-reviewed spreadsheet:

Check	Example Error
Leading/trailing spaces	" Status Name " → trim it
Copied suggestion text	"Status Name (85%)" → remove percentage
Invalid actions	"map" → should be "MAP"
Typos in target names	"Aproved" vs "Approved" in target
Duplicate targets	Two sources → same target (conflict)

Safe Cleanup with JQL Validation

The generated Groovy cleanup script doesn’t blindly delete. It verifies first:

// Before deleting a status, verify no issues use it

def jql = "status = \"Old Status Name\""

def issueCount = countIssues(jql)

if (issueCount > 0) {

println "SKIPPED: ${statusName} - ${issueCount} issues use this status"

} else {

// Safe to delete

statusManager.removeStatus(statusId)

}

Real-World Results

On a recent migration project:

Metric	Manual Approach	With Toolkit
Objects processed	500+	500+
Time to generate mappings	~8 hours	~10 minutes
Human errors caught	Found in UAT	Found before CMJ import
Cleanup confidence	“Hope nothing breaks”	JQL-validated, audited

Getting Started

The toolkit is open source and available at GitHub.

Prerequisites

Python 3.8+
CMJ installed in target Jira
ScriptRunner for target data export and cleanup execution
Access to source and target Jira REST APIs

Quick Start

# Clone the toolkit

git clone <repository-url>

cd cmj_template

# Install dependencies

pip install -r requirements.txt

# Validate your setup

python3 scripts/run_migration.py --validate

# Run interactively

python3 scripts/run_migration.py

The Workflow in Practice

Pre-Deployment: Data Collection (Steps 1–2)

Export data from source and target Jira instances, converting to Excel for the audit trail:

python3 run_migration.py --step 1 # Convert source data

python3 run_migration.py --step 2 # Convert target data

Output: Excel workbooks with all objects, IDs, and metadata—easy to review and share.

Pre-Deployment: Process & Validate (Steps 3–5)

python3 run_migration.py --step 3 # Process customer mapping

# → Customer reviews the PROCESSED.xlsx file

python3 run_migration.py --step 4 # Validate reviewed file

python3 run_migration.py --step 5 # Filter for CMJ template

The validation step is critical. It catches mistakes before they become CMJ import failures.

Pre-Deployment: Generate CMJ Templates (Step 6)

python3 run_migration.py --step 6 # Generate CMJ XML templates

Output: Two CMJ template files ready for import:

global_cmj_template.cmj — Statuses, Resolutions, Link Types, and Issue Types
custom_field_cmj_template.cmj — Custom Fields (imported separately due to size)

These templates are generated directly from the validated mapping spreadsheet, ensuring every MAP operation has been reviewed and approved before it touches CMJ. No more manual XML editing or copy-paste errors.

CMJ Deployment

Import both templates into CMJ and deploy your snapshot. This step remains manual—the toolkit hands off cleanly-formatted, validated input so the CMJ deployment itself is straightforward.

Post-Deployment Cleanup (Steps 7–11)

After CMJ deployment, export the new target state and generate the cleanup script:

python3 run_migration.py --step 7 # Convert post-import data

python3 run_migration.py --step 8 # Generate cleanup report

python3 run_migration.py --step 9 # Generate Groovy cleanup script

python3 run_migration.py --step 10 # Validate dryrun output

python3 run_migration.py --step 11 # Validate liverun output

The two-phase validation (dryrun then liverun) ensures nothing gets deleted that shouldn’t be.

Lessons Learned

Validate Early, Validate Often

The #1 cause of CMJ failures in our experience: bad input data. A typo in a target name, an extra space, a copied suggestion with “(85%)” still attached. Catching these before CMJ import saves hours of debugging.

Protect What Existed Before

Objects that existed in the target before migration should never be deleted. The toolkit tracks pre-import state and protects those objects during cleanup.

Trust but Verify (JQL Checks)

Even after careful planning, always verify with JQL before deleting:

status = "StatusName" → Any issues using this status?
"FieldName" is not EMPTY → Any issues with data in this field?
issuetype = "TypeName" → Any issues of this type?

Keep the Human in the Loop

Automation handles the tedious work. Humans make the decisions:

Should this source status map to “Done” or “Closed”?
Is this fuzzy match correct, or should we create a new object?
Which of these conflicting mappings wins?

None of This Works Without the Right Customer

Tools like this don’t get built—or validated—in a vacuum. A critical ingredient in making this toolkit production-ready was having a customer who was genuinely invested in getting it right.

Ryan Stroup dedicated real time and attention to this effort: reviewing mapping spreadsheets, testing the pipeline against his projects’ actual data, surfacing edge cases that only appear in production environments, and validating that every requirement was met before sign-off. That kind of engaged partnership is what separates a toolkit that works in theory from one you can trust on a live migration.

If you’re planning to adopt this approach, I’d strongly encourage the same model: identify a customer stakeholder who will roll up their sleeves and test alongside you. The automation handles the tedious work—but a willing, thorough collaborator on the customer side is what gives you confidence the output is actually correct.

Built with AI: A Claude Code Story

Full disclosure: this toolkit was built collaboratively with Claude Code, Anthropic’s AI-powered CLI assistant.

What started as a few helper scripts evolved into a comprehensive 11-step pipeline through iterative development with AI assistance. Claude Code helped with:

Rapid prototyping — Describing what I needed and getting working code in minutes
Edge case handling — “What if the customer copies the suggestion text with the percentage?” became a validation rule
Refactoring at scale — Restructuring the entire pipeline from 8 steps to 11 steps with proper validation
Documentation — Generating consistent docstrings, README updates, and yes, even this article draft

The experience reinforced something important: AI doesn’t replace domain expertise—it amplifies it. I knew what CMJ migrations needed; Claude Code helped me build it faster and with fewer bugs than I could have alone.

If you’re on the fence about using AI tools for Jira administration work, I’d encourage you to try it. The combination of your Jira knowledge and AI’s coding assistance is genuinely powerful.

Conclusion

CMJ is a powerful tool, but it’s only as good as the data you feed it. This toolkit fills the gap between “we have a mapping spreadsheet” and “CMJ templates are ready to import” with:

Automated matching and validation
Conflict detection before it’s too late
Production-ready CMJ XML templates
Safe, audited post-migration cleanup with JQL validation
Excel audit trails for everything

Whether you’re migrating one project or fifty, having a repeatable, validated process makes all the difference.

The code is on GitHub. If you run into issues or have improvements, feel free to open an issue or PR.

Questions or feedback? Drop a comment below or reach out directly. I’m always interested in hearing how others are tackling Jira migrations—and whether you’re using AI to help.

Struggling to understand who’s working on what in Jira, so I built this

Dario Sanatkar — Wed, 08 Apr 2026 15:28:43 GMT

Hi everyone 👋

I recently ran into a problem while managing our employees/users across several Jira spaces in my company.

We have around 150+ users in our instance, and it became surprisingly difficult to answer simple questions like:

Who is working on what?
Which users have access to which projects?
How active is that user in that project?
What is that user's workload in that project?

Jira is great, but I found that getting a clear, centralized view of users, roles, and activity across projects wasn’t straightforward. For example, before, I had to open each project and check which users were assigned to it.

So I decided to build a small Forge app to solve this for our internal needs: User manager for Jira (https://marketplace.atlassian.com/apps/2258788102/user-manager-for-jira)

It gives a single dashboard where you can:

See all users and their project involvement
Understand workload, roles and permissions quickly
Monitor activity and identify unused or misconfigured access

It started as an internal tool, but I’m now exploring publishing it on the Jira Marketplace.

Curious to hear:
👉 Is this something others have struggled with as well?
👉 How are you currently managing user visibility at scale?

Happy to share more details if anyone’s interested!

🙏 Thank you!

Welcome Wednesday: What clever Wi-Fi network names have you seen?

Dave LIAO — Wed, 08 Apr 2026 09:51:55 GMT

G'day Atlassian Community! 👋

It's time for another Welcome Wednesday - for this week, I'd like to know: what interesting Wi-Fi access point names have you seen?

Or maybe: what have you named your Wi-Fi networks? 🙃

📣 Sound off in the comments!

Tuesday Jira Vibes - Do’s and Don’ts for managing sprints in Jira

Daria Kulikova_GitProtect_io — Wed, 08 Apr 2026 08:54:47 GMT

Hello, New-to-Jira folks and curious Agile minds! 👋

The latest discussion of Tuesday Jira Vibes is here, though it looks like Wednesday Jira Vibes :)

Well, let’s talk today about something that can either make your team feel like a well-oiled machine… or like you’re constantly putting out fires 🔥

… sprint management in Jira.

Let’s be honest, a sprint is not just a timeline. It’s a commitment, a shared focus, and (sometimes) a reality check 😅

When managed well, sprints bring clarity, predictability, and momentum.
When managed poorly… it can lead to chaos and overloaded teams.

So what are Do’s and Don’ts for managing sprints in Jira?

✅ DO’s: What actually helps your sprint run smoothly

Set a meaningful sprint goal, as a sprint without a goal is just… a list of tasks. Example? Use the Sprint Goal field in Jira.
Refine your backlog before planning, because if your backlog isn’t ready, your sprint won’t be either.
Keep the sprint stable; mid-sprint changes are tempting… and sometimes unavoidable. But constantly adding or removing work? That’s where things fall apart.
Use JQL to make planning easier - instead of manually searching for what you need, try using JQL, like priority = Highest AND Sprint IS EMPTY
Plan as a team, as sprint planning is not a one-person show. The best plans come from shared understanding between all teams - developers, product owners, and everyone involved. When the team plans together, it improves estimates, increases ownership, and decreases surprises.

Close sprints properly - it may sound simple… but it matters. Always complete your sprint from the same board where it was created. Why? Because Jira reports depend on consistency. And broken data = misleading insights.

❌ DON’Ts: What quietly breaks your sprints

Don’t treat planning as PO-only. Sprint planning is not just about what to do, but it’s more about how to do it. If only the Product Owner drives it, you might miss technical insights, realistic estimates, or team buy-in. Planning is a team sport.
Don’t overcommit, as planning 100% capacity sounds efficient… but it’s risky. There can always be some either unexpected bugs, or meetings, or context switching. Leave some breathing room. Your future self will thank you 🙂
Don’t delete issues mid-sprint, though it might seem harmless… it still breaks your reports. What to do instead? Move unfinished work back to the backlog, for example, or into the next sprint. Data matters, and Jira tells a story, so don’t erase parts of it. Moreover, there is compliance; it’s better not to break it.
Use multiple boards for one team. Remember, one team = one board. Splitting across boards can lead to confusion, inconsistent tracking, or even broken visibility. Keep everything in one place, as simplicity always wins.

So now I’m curious 👇

What’s the one sprint habit that made the biggest difference for your team?

Or which “Don’t” have you learned the hard way?

Or what other Do’s and Don’ts would you add to this list?

A Little About Me: Backend Builder & Team Player 🚀

Bikash Kumar Panigrahi — Wed, 08 Apr 2026 04:54:08 GMT

I’m a backend enthusiast with a growing toolkit built around Java and Python, and a strong interest in designing systems that are reliable, scalable, and easy to maintain.

I’m particularly drawn to the backend because I like:

Breaking complex problems into smaller, testable pieces
Thinking about architecture and data flow end-to-end
Making sure what we build can be observed, debugged, and improved over time

On the interpersonal side, I try to bring a collaborative, curious mindset:

I ask a lot of questions and love learning from more experienced engineers
I enjoy pair programming and code reviews as a way to share knowledge in both directions
I’m comfortable admitting when I don’t know something and using that as a starting point to learn
I care about clear communication—whether that’s a Jira ticket, a Confluence page, or a quick sync with the team

suggestion to add acronym library or similar

Caprice Stevenson — Wed, 08 Apr 2026 03:43:46 GMT

have you considered an acronym library or 'what's this?' type explanation similar. I noticed quite a lot of technical jargon that could benefit from having a quick guide to give nice clear unambiguous definitions

Reporting Lines

Kelly Fiorella Drozd — Tue, 07 Apr 2026 21:07:32 GMT

Hello, As we are starting to role out the use of goals and projects across some of out strategic programs and initiatives, we were interested in Reporting Lines, unfortunately the documentation that is linked says that the only option are still Okta and Azure?

I clicked on the sign-up here link to be informed when additional providers are supported - but that opens a google form for Atlas - so not sure how update to date that is or not.

We do currently have Atlassian Guard but our Identity Provider is Rippling. It seems Rippling passes through a manager's email to Atlassian but that is its and there is not much we can do with that.

We do have Ripping connected to our Google workspace that passes through managers but again, it seems like the only option for reporting line is Okta and Azure.

Are there any updates on reporting lines or work arounds to this. I assume leveraging teams is an option but it's an extreme amount of manual work to rebuild the org there and keep it updated.

Thanks

ASOJEC Niger salutations

Boubacar Mamoudou — Tue, 07 Apr 2026 20:50:02 GMT

Hello everyone. Im Happy to be part of this communauty. How activities?

Are there plans to expose Jira Product Discovery fields through the MCP connector?

Sara Radkiewicz — Wed, 08 Apr 2026 15:22:48 GMT

Without exposure of these fields, it makes JPD much less useful to me - claude can't help create powerpoints w/o too much intervention and I have to re-type all the fields in the description - and it's an overall PIA. I will probably need to shop around for a planning tool that better integrates with AI if this isn't added soon.

Hi I'm new here

malyone88 — Tue, 07 Apr 2026 19:18:26 GMT

Hi, my name is Jamal Jones. I am visiting this website for the first time. I really want more information on how to make the most of it.

Hi!

Rafael Lyra Teixeira — Tue, 07 Apr 2026 19:13:35 GMT

Hello! I am very exited and happy joining this community!

Jira app for comment audit log - looking for a few design partners

johnsusek — Tue, 07 Apr 2026 18:49:56 GMT

Hi everyone,

I'm working on CommentLedger, a Jira app focused on giving teams an audit trail for comment creates, edits, and deletions in Jira.

I'm looking for a small number of early design partners - not passive beta testers, but teams willing to try it in real workflows and give blunt feedback.

I'm trying to learn if this is useful enough to buy, if there are any features missing, if there are any trust/permission issues, etc.

- try it on a real Jira Cloud site

- give honest feedback

- get direct influence on roadmap

- get early access to new features

- fast founder support

- acknowledgment as a launch partner, if desired

If this sounds up your alley, reply here or send me a message.

Thanks!

-John

🤝 Anyone coming to Team '26 in Anaheim? Interested in a Philly meetup?

Dave LIAO — Tue, 07 Apr 2026 14:41:55 GMT

Hi Philly Community folks!

Atlassian Team will be here in just 28 days - will you be attending? (In case you're not already getting marketing emails for the event, click here to learn more about Atlassian's annual conference.)

I'll be there! I'd love to meet other Philly area Atlassian practitioners.

📢 If anyone is interested in a low-key meetup, just leave a comment here 🙌 Maybe it's your first Team, or you don't know anyone going? Whatever your reason, all are welcome.

p.s. If you want a discount code for Team, also comment. I think I have a code lying around here that I can share...

Align Salesforce and Jira Service Management for Faster Incident Resolution

Twinkle Dhawan — Tue, 07 Apr 2026 13:33:37 GMT

Efficient incident management depends on how well customer-facing and engineering teams stay aligned. If your teams use Salesforce for customer operations and Jira Service Management (JSM) for incident handling, integrating the two can significantly improve response times, visibility, and collaboration.

Sinergify simplifies this integration, helping both teams stay in sync without manual updates. In this guide, we’ll cover the benefits and how to set up a reliable Salesforce–JSM integration.

marketplace.atlassian.com

Why Integrate Salesforce and Jira Service Management?

Connecting Salesforce and Jira Service Management helps eliminate silos between support, sales, and engineering teams.

Here’s what improves:

Better Collaboration: Salesforce cases can be linked to Jira incidents, giving engineering full context
Real-Time Updates: Changes in Jira reflect in Salesforce (and vice versa) automatically
Faster Incident Resolution: Teams track progress without chasing updates
Improved Customer Communication: Customer-facing teams always have the latest incident status

Four Fields That Actually Matter

To keep teams aligned, sync these from Jira to Salesforce:

Incident Start Time for shared timeline
Outage Duration for SLA tracking
Root Cause for clear communication
Customer Impact for better prioritization

Key Features of Sinergify’s Salesforce–Jira Integration

Bi-Directional Sync: Keep Salesforce and Jira aligned in real time
Comment Visibility Control: Safely manage internal vs external communication
Custom Field Mapping: Sync fields like incident start time, root cause, and impact
Workflow Automation: Auto-create Jira issues from Salesforce and sync status updates
Reduced Context Switching: Access all incident data directly in Salesforce

Start Aligning Your Teams Today

Sinergify makes it easier to connect Salesforce and Jira Service Management, helping teams respond to incidents faster and with better context.

Whether you're handling outages, escalations, or service requests, a well-integrated system ensures smoother workflows and better customer experiences.

Ready to get started? Check our detailed guide here and set up your integration today!

Is it worth taking a free and open‑book certification?

WESLEY DE SA TELES — Tue, 07 Apr 2026 13:01:09 GMT

If you follow the process: absolutely!
The fact that a certification is free or open‑book does not diminish its importance.
Study the tool, complete the official training, and understand the message they want to convey.

My case:

I never imagined that a video‑recording tool could offer so many productivity features like Loom.
Understanding how Rovo can help teams deliver value with less effort: AI is just technology, how you use it is what makes the difference!
Forge is an incredible Serverless Rapid Development Platform for building applications in the Atlassian ecosystem --> Powerful.

My advice:
Enjoy the journey, engage with the community, learn something new.
You'll be surprised by your progress!

Rovo AI configuration

Maurice Adams — Mon, 06 Apr 2026 18:08:09 GMT

Is there a time where the AI Rovo agents you can build will have a way to customize the chat window with the same Icon used in the configuration of the portal? Also is there a way to have the chat window to appear for use first and disable the service portal until there is human interaction that cancels the chatbot and proceeds with the service portal and groups we created with forms?

Basically a Bot only option first, then to my Customer Portal or Help Center

IA (ROVO) and human intervention

Fadi Messaoudi — Mon, 06 Apr 2026 14:33:13 GMT

Is there a possibility that Rovo or other AI tools will eventually replace Atlassian consultants?

AI TEST STUDIO - Turn Jira issues into review-ready test cases for Xray and Zephyr with AI GPT 5.4

AI Test Studio — Mon, 06 Apr 2026 07:14:11 GMT

AI Test Studio helps Jira Cloud teams generate high-quality manual test cases and Gherkin scenarios from issue content, configurable Jira context, and supported attachments. With a review-first workflow, teams can inspect, select, and publish approved output into Jira, Xray Cloud, or Zephyr Scale / Essentials without giving up control of their QA process.

We’ve continued improving AI Test Studio for Jira Cloud teams that want faster test design without losing control over what gets created.

AI Test Studio is built for teams working in Jira, Xray Cloud, and Zephyr Scale / Essentials that need more than generic AI output. Instead of generating tests from a single text field, the app can use issue summaries, descriptions, acceptance criteria, configurable Jira fields, and supported attachments to produce more relevant and practical test coverage.

What it does

AI Test Studio helps teams generate:

Structured manual test cases
BDD / Gherkin scenarios
Output based on real Jira context
Reviewable results before anything is created downstream

Why it matters

For many QA teams, the challenge is not just generating tests quickly — it’s doing so in a way that still fits existing workflows and quality controls.

AI Test Studio is designed around that need:

Review-first workflow
Generated tests are reviewed before creation, so teams stay in control and avoid noisy or low-value output.
Built for Xray and Zephyr workflows
Approved test cases can be created directly in Jira, Xray Cloud, or Zephyr Scale / Essentials, helping teams keep their current toolchain and traceability model.
More useful input, not just more AI
The app supports richer generation using Jira issue content plus supported attachment formats including images, PDF, Word, Excel, PowerPoint, TXT, Markdown, HTML, CSV, JSON, XML, and RTF.
Safe regeneration
When AI-generated tests already exist, teams can regenerate safely by unlinking prior results instead of deleting earlier issues.
Admin governance controls
Administrators can restrict usage by project and issue type, and choose which Jira fields are included as AI context.

In the Jira issue UI, AI Test Studio seems to be presented as an embedded app or extension linked to the current ticket. To use it, the user likely has to open the app from the issue view or enable its panel if it is currently collapsed or not yet activated.

Privacy and operational approach

AI Test Studio is designed with a privacy-aware, data-minimization approach for teams in the EU and US. The service is designed to avoid retaining Jira issue content and attachments outside Atlassian after processing wherever possible, except where users intentionally publish approved output into Jira or connected tools.

We’d love community feedback

I work for the team behind AI Test Studio, and we’d genuinely value input from the Atlassian Community.

If your team works with Jira, Xray Cloud, or Zephyr, we’d be very interested in hearing:

what workflows you’d like supported
where test generation still feels slow or incomplete
what edge cases matter most in real projects
what improvements would make the app more useful for your QA process

We’re happy to discuss questions, workflow ideas, and product improvements, and community feedback can directly shape future enhancements.

For more details, installation, and support:

Marketplace listing: AI Test Studio on Atlassian Marketplace
Documentation: https://aiteststudio.com/docs
Support: contact@aiteststudio.com

Looking for a Sales Manager!

Mary from Planyway — Mon, 06 Apr 2026 03:17:00 GMT

Sales Manager (Atlassian Marketplace, B2B SaaS)
Remote • Planyway • Salary + bonus from new clients

Visual planning and tracking for Jira and Trello

Every day, thousands of teams plan projects in Jira and Trello with Planyway.
Planyway gives teams a live dashboard to know exactly who’s doing what, when they’ll ship, and where time really goes. Over 1M users worldwide, paid customers: Netflix, Apple, IBM, BCG etc.

Your job will be simple: meet new trial Planyway users, show demo, and turn into paying customers. Also you need to manage the reseller partnership channel. You will work with customers from the US, Europe, and global startups. The friendly Planyway team will support you along the whole workflow.

This role is perfect for someone who:

Enjoys product demos and closing deals
Likes helping customers and partners, ensuring that real value has been provided
Wants to earn based on results, not just hours
Wants to work remotely, preferred (but not limited) locations: Portugal, Spain, Serbia, Kazakhstan or Argentine

What success looks like (first 3–6 months)

The main goal is to lead Planyway product sales through a consultative approach, involving both hunters (new business) and farmers (expanding relationships with existing customers).

In this role, success means:

Running 15-20 product demos per week
Converting qualified leads into paying customers
Consistently closing deals from inbound leads (trials)
Building sales with Atlassian partners as a channel
Building strong strategic relationships with customers
Providing feedback that helps improve the product
Reaching monthly revenue targets
Becoming a trusted advisor for teams evaluating Planyway

The requirements that really matter

3+ years in B2B sales (B2B SaaS only)
Worked for project-oriented tool vendors like Tempo, Asana, Monday
Experienced selling within the Atlassian Marketplace
Has project management experience (especially in Jira)
IT or tech background
Fluent English, can comfortably understand natural spoken American English
Availability in US time zones

Why people like working with us

Friendly and supportive team, obsessed with Planyway
International product with the best user interface
Small team, fast decisions
Direct impact on product and fast growth

Hiring process

We review all CVs every week
Candidates who match the role are invited to an intro call
Intro call (30–60 min)
Demo simulation
Final conversation
Decision is usually made within 1–2 weeks

How to apply

Add a short note about your sales experience and results in your cover letter
Answer our questionnaire (please answer in English)
Submit your CV at support@planyway.com

We are excited to see you in our team!