• 

• 

• 

• 

Update 2016: Relations for JIRA is now called Atlas CRM

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.

Problem

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.

Vision

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.

Roadmap

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

• amazon-web-services
• atlassian-connect
• aui
• clojure
• clojurescript
• datomic
• re-frame
• react