Activity
Mon
Wed
Fri
Sun
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
What is this?
Less
More
Memberships
Atlassian Everything
271 members • Free
28 contributions to Atlassian Everything
5d •
Jira Service Collection Apps
I have been anxiously awaiting the arrival of Jira Customer Service Management to my cloud premium tenant for months now. As I have been an Atlassian customer for over 5 years, my tenant already existed at the time of the announcement. It was my understanding that existing customers would begin to see the Customer Service Management app appear starting in Feb 2026. Anyone have any idea when I might see mine show up? FYI, I reached out to the Atlassian Community and got zero answers. I reached out to Support and they didn't seem to even know that CSM was a thing. Any insight someone can share would be welcome. Thank you!
1 like • 19h
I played with CSM a few weeks ago and was left with the impression that it's half-baked and wasn't clear on where to use it versus a traditional JSM project. Hopefully as it evolves, there will be a clearer separation between JSM and CSM.
20h •
Use Jira instead of XL
My team has all the task listed in an xl sheet Is there a way I could use Jira to manage them effectively?
0 likes • 19h
Hi @Dipesh Karania, The short answer is yes! There is a bit of a tendency to overcomplicate Jira when starting but I've found the most effective approach is to start with something simple like a To Do, In Progress, Resolved/Done and just start getting tasks into a central place people can see it. You don't have to get more complicated then that :)
11d •
Components
Anyone using components, in what way and/or use cases, best practices? I found this function and unsure how to feel about it. I rather have Space Owner being the Assignee, unless we work in teams and implement round robin or automations (for a junior role for onboarding, etc.)
1 like • 7d
To tag on to Alex's point, you can use them as a pseudo-drop down field that space admins can control without requiring a Jira admin. The component lead/assignment functionality doesn't have to be used, but if you have members of a team that handles specific things (e.g. Scripting issue -> Chris, UX -> Alex), it's a built-in way of doing that without using automation rules.
13d •
Migration to Atlassian Cloud is the Perfect Time to Transform | Rovo Can Help
Came across an interesting article by Aaron Geister and Dave Rosenlund on LinkedIn today. I didn't have the benefit (or curse?) of having Rovo available as a tool for previous migrations, and while I'm not quite sold on Rovo's capabilities (yet), it's definitely an interesting take and worth a read! Even without Rovo, the article offers some good cloud migration nuggets. https://community.atlassian.com/forums/Rovo-articles/Migration-to-Atlassian-Cloud-is-the-Perfect-Time-to-Transform/ba-p/3195993
24d •
Custom Fields
New to Jira, new to this community, and first post. Be nice...... I have what is probably a dumb question. It's certainly not my first and won't be my last so here goes. Is there a best practice when creating custom fields to keep the naming conventions "coherent"? I will give an example. We created some site locations in assets (For instance a branch office located in Chicago). We added in "Address" as one of the fields and then built that into some automations. However soon after we realized that sometimes we deal with a "physical" address and sometimes it's a "mailing" address. So now we need to go back and fix what we set up. Not a big deal in this case. However, I can see that once you have many different teams and spaces set up, this could get messy very quickly. How to others map this out better from the get go? Any advice would be appreciated.
0 likes • 19d
@Colin Bemus there are no dumb questions :) As always, the answer depends a bit on your organization, but a helpful rule of thumb is to use reusable field names wherever you can. To use a super basic example, if you have a client group that wants an "Engineering Stakeholder" field but all they ever have are engineering stakeholders, why not name the field "Stakeholder" instead? There will be use cases where you need to name a field super specifically, and that's okay, but you want them to be the exception, not the rule. One organization I worked for had 10 different due date fields (e.g., Engineering Due Date, Marketing Due Date, etc.), but none of the projects ever used more than one of those dates and could've easily used the existing due date field.
1 like • 19d
@Colin Bemus as with anything, it's a bit of a balance and as @Alex Ortiz mentioned above, it can sometimes be an art more than a science. You want to be clear enough what the field is for without having 15 copies that serve the same purpose.
1-10 of 28
@chris-rogers-3182
Atlassian Certified Administration Expert and overall Atlassian enthusiast
Active 2m ago
Joined Nov 5, 2025
Edmonton, Alberta, Canada
Powered by