Update 2016: Relations for JIRA is now called Atlas CRM

Atlas CRM Logo

We have renamed Relations for JIRA to Atlas CRM. After launching the add-on, a lot of people gave us feedback on our old name and the cultural meaning behind the word "Relations". We were not aware of this when we joined Codegeist in 2015, but decided to change it to Atlas CRM few months after.

Relations for JIRA

Relations for JIRA introduces companies and contacts as first class citizens in JIRA. These new entities provide the context business teams need to take full advantage of the power of JIRA.


JIRA is expanding beyond the development world by releasing JIRA Core. JIRA Core is a very powerful and flexible tool that helps any kind of business team for any project. But something is missing.

Many business teams don’t work from a project perspective only. Their work is often people, customer or company related. We call these 'relations'. Here are a few examples:

  • A HR team that is looking for new developer talent
  • A sales team that is selling a new product to its customers
  • A finance team that is creating invoices for resellers

Relations have a central role in these business teams, but don’t have a dedicated place in JIRA yet. We’ve seen some teams solve this by using custom fields or by linking to external software. But when the list of issues grows over time, this leads to outdated information scattered across issues and big administrative problems.

Solution: Relations for JIRA

Relations for JIRA introduces companies and contacts as first class citizens in JIRA. These new entities provide the context business teams need to take full advantage of the power of JIRA.

Each company and contact has its own space in JIRA. This space offers teams an overview of everything that's going on with this relation. In this space, teams can add information about the company or contact, such as: contact information, roles, important URL's and so on.

Once company and contacts are created, you can make their information available by linking them to relevant JIRA issues. Users can effortlessly link to a company and/or a contact within the issue. This allows users to access company and contact information from the issue directly (who's paying, who's in charge, who should I call, what is their phone number, etc.). They no longer need to add this information to custom fields or to link the specific issue to an external CRM. Instead, the information is managed centrally in the company or contact itself and is linked to one or more issues.

The link between company and contact goes further than just providing contextual information within the JIRA issue. In the company space you can view all issues that are linked to the company. This is where it gets really interesting as you now have a complete overview of all issues relating to a particular relation. Teams can filter these issues on project, issue type, status or even do a basic search. To give an example, this means that you could instantly view all unresolved feature requests / support issues / bugs, etc., across all your projects, belonging to a particular customer.

Whatever your team needs to know about a relation, they can now see it in Relations for JIRA.


We’re currently working very hard to finish the strong core of Relations. While we designed and developed this core, we had a vision in mind about the way we store and use data.

In the mindset of RDF and triple stores, we store data with meaning (street, phonenumbers, email, etc). This allows for integration with all sorts of services as we have a good understanding of the meaning of the data. It also helps our users to mix, expose, and share their data across different applications.

The next thing we want to do is help our users as much as possible. A lot of the data about companies, for example, is available online. Think schema.org, Open Graph protocol etc. We could, for example, suggest contact information for a company when we know the company website, so our users don’t have to look it up. We believe that by helping our users like this, they’ll have more time to focus on their work.


Our roadmap for the moment is quite simple, finish the core of Relations. We’re currently working on these things:

  • Adding contact overview
  • Supporting JQL
  • Link to (confluence) documents

In the meantime, our first JIRA Cloud users are already using our product. This is great as we’re very eager to learn from them. We have adopted a LEAN approach for our design and development, which means that we want to learn from our users as much as possible. Design and development decisions will be based on how our users use the add-on.

How we built it

We started building this add-on because some of our colleagues had a serious need to manage their relations in JIRA. After some research, we noticed that many people were looking for some sort of CRM functionality in JIRA. We weren't sure what people were looking for exactly though... This is why we built an MVP Server version of Relations and shipped it internally and to a dozen customers for feedback. And boy, we learned a lot from that! The #1 feedback we got is that people definitely needed this add-on.

Even though we were using Server ourselves, like most of our clients, we decided to focus our efforts on JIRA Cloud at first. Why? Because we realized that the challenges for the Cloud version were an order of magnitude more complex, that decisions would be harder and that the technology would likely slow us down. But going through this tougher road would ultimately help us later when going back to Server and it would allow us to reach way more users right from the start.

Looking back, we're glad we went down this road. It's not that we have an exciting feature list, but we know that we have a very strong core and that what we have, we can build on.

We chose technology that would allows us to build on an amazing stack, but also port as much code as possible back to the Server version. All of the front-end code is therefore written in ClojureScript. The backend is written in Clojure with a strong dependency on the Datomic transactor. For the Server version we will match that with a triple/quad store implementation of a Sesame RDF store that will use Active Objects for storage. But that's enough buzzword-bingo.

Challenges we ran into

The first challenge we took on was to write our own Connect framework implementation in Clojure. We kind of reverse engineered the existing Java and NodeJs frameworks into a Clojure version. We are glad we did this for the full control it gives us for that part.

Another big challenge, that is completely unrelated to technology, is the place where the data lives. Suddenly the data does not live inside a customer's JIRA, but we are responsible for it. We must do the best we can to make Relations for JIRA a safe place for our customer's data. Legislation from all around the world will play a big role in this, as we are storing sensitive and personal data.

Other challenges include the limitations the Connect framework imposes on our work. This is of course all relative to what we are used to in writing for Server add-ons. Connect is great as an idea/architecture, it just needs a bit of work on both Atlassia's side and the add-on vendor side...

Built With

+ 19 more
Share this project:


posted an update

Hey everyone, thank you very much for liking our Codegeist entry for 2015. This year we have also entered the Codegeist project, but this time with an add-on that integrated StatusPage with JIRA Service Desk.

Read all about it on the Codegeist page here: http://devpost.com/software/statuspage-for-jira-service-desk. And don't forget to vote for this years Codegeist hackathon. You only have 4 days left to vote!

StatusPage for JIRA Service Desk

StatusPage for JIRA Service Desk

StatusPage for JIRA Service Desk

StatusPage for JIRA Service Desk

Log in or sign up for Devpost to join the conversation.

posted an update

Issue search

Hi everyone, today I’d like to show you something you might have missed when using Relations. I hope so at least, because it would mean that we achieved one of our goals. I’m talking about the user interface of the add-on.

During the design and development of the add-on, we’ve gone out of our way to make Relations look and feel as close to JIRA as we could. We’ve dissected the Atlassian design guidelines, the Atlassian front-end library and the latest version of JIRA to find out exactly how we could do this.

In many cases, this meant using the front-end library provided by Atlassian. But even this library has a limit, not everything is included. Who would, for example, want to include the filters in the basic issue search?

Well.. we do. In the first version of Relations, our users could view all issues linked to a company and query over them using JQL (the query language used to search for issues in JIRA). While JQL is a great language for this, we wanted Relations to be user friendly for anyone. Why would you manage your relations in a tool that some of your colleagues can’t use?

This is why we’ve decided to replicate some UI elements, such as the basic issue search. The decision wasn’t easy. First of all, it costs a lot of time and effort to replicate a UI into detail. Any small difference will be noticed immediately. Secondly, if Atlassian decides to redesign this part of the UI, we’ll have to follow them. And as Atlassian is always improving its products, this happens quite a lot.

So why did we do it then? Easy, for our users. By staying close to the JIRA UI, our users will immediately recognise the UI and know what they can do. There’s no need to learn new UI elements and conventions.

Want to see what it looks like?

Basic issue filter in Relations for JIRA

Basic issue search in Relations for JIRA

Log in or sign up for Devpost to join the conversation.

posted an update

Hey everyone, here’s a quick update on our progress. While a part of the team has focussed its efforts on content for Codegeist, development of the add-on did not stand still. We’re making real progress and we want to give you an update.

Due to some technical challenges in our approach and the connect platform, we expected that JQL integration would get very complicated. Fortunately though we were able to find a very good solution. You're now able to search by company or by contact!

JQL Screenshot

We’ve also added the contact information page. Contacts are now almost on par with companies, functionality-wise. We’re going to refine the contact information page and will be adding the issues overview somewhere this week.

So stay tuned for more!

Log in or sign up for Devpost to join the conversation.

posted an update

Thank you!

Our first users have started using Relations only a few hours after we released it in the marketplace. We’ve never experienced such a quick response with any of our other add-ons, so naturally we were quite surprised!

Now, x days later, we have a modest amount of trial users who are managing companies and contacts in Relations. We have active conversations with any user that wants to tell us their story and their experience with the add-on. And we’re slowly but steadily learning more and more about them and their goals.

I know we’ve said this many times before, but we mean it when we say that we love hearing from our users! So keep sending anything that’s on your mind, good and bad, we can handle it. Your feedback has helped us fix a few bugs already and helps us learn about more and more the add-on.

So thank you guys! You’re great!

Log in or sign up for Devpost to join the conversation.