Rixter Products

Enjoy your stay mate!

We at Rixter are continuously working on delivering the best products on the market to make your day to day tasks as easy as possibly, whether you are an admin, user or any other role.

Checkout our products in the list below.


Cloud Product status

Checkout our current product status


Do you have any questions or in need of support then feel free to use our first class support via the portal: Rixter Support Portal

Watch the video of Rixter at the Atlassian Community event in Cyprus to present our products.

It'll show you how we were asked to demonstrate powerful features from our products.

By joining the Atlassian Community, everyone can gain access to new innovative ways of working together and make the most out of the software they already use.

Click here to see the video at Youtube.


Vancouver Webinar iHub

Phoenix Webinar iHub
Build Integrations behind Firewall

The problem

Today many JIRA servers are located inside the companies firewall, which makes it hard to do two way integrations. In many cases you don´t want to expose the whole JIRA instance to the internet. Since JIRA default only handles Basic Authentications and might be seen as to unsecure.

This causes integrations to only be setup using a one way flow. There is normally a huge value by doing this, but the value can be even higher if allowing the other system to talk back to JIRA. This article shows how you can do this in a secured way.

The solution

iHUB Incoming rules! By utilizing the incoming rule engine in iHUB you will be able to setup a specific URL that the internet can access, and that URL can be secured by first of all using token urls. That is basically a url constructed using a GUI or Token.

The Token URL

A token URL can be formatted in many ways examples:

It is essentially a unique URL that is super hard to guess or to find out.

The firewall

On the firewall, add a rule that only allows this URL to be accessed from the outside, so whenever a service send a request it goes to that URL.

That URL can then be connected to one or more iHUB incoming rule(s).

The Rule Engine user

Second part of the security is that you setup a user with no Application Access in JIRA, meaning that user can never directly do anything in JIRA. Let´s call this mr.hello, that user in JIRA does not require any license either.

mr.hello role is to simply login to iHUBs incoming rule and pass the data to the rule engine.

The iHUB Incoming rules

Once the call has passed the firewall and login the rule engine takes over and validates on any of these three things;

  1. Correct incoming URL is called mapped to any rule - Always used for security reasons but not required for internal services.
  2. Correct user calls the rule
  3. Data condition - does the rule has the right data


The rule engine maps the request to an action

The Action

The action is the actual work that needs to be done. It will call any REST service, but it most cases it will call the JIRA REST API to perform updates.

So for example an Incident might be triggered in ServiceNow and sent through to an action, the action then takes the data and map that to a JIRA issue and creates that issue.

Here is the second authentication, where the triggered call is always run by a action user, in this example below the JIRA_INT_USER performs the call towards Jira and has the Application Access and roles needed in the project(s) that this integration relates to.


To summarize, open a single url in the firewall that only allow traffic to iHUBs rule engine. Create a user that can login to the rule engine and trigger actions based on the conditions. Setup an action that will be triggered by a rule. Let the action do the integration work mapping data and creating tickets.

In this article, you will learn how to have two Jira instances synchronizing issues between each other using the "Integrations Hub for Jira" app.

The iHub can be downloaded here: https://marketplace.atlassian.com/1220905

Why running multiple instances?

The reasons for running multiple instances varies depending on the use case.

For example:

  • Your company has separated customer support and development Jiras
  • You have an outsourced department using a separate Jira
  • You've merged with another company ending up in multiple Jira instances

The problem

Jira does not support synchronizing multiple instances out of the box, you will need a third-party app to do do this. This article will show you how to do this with the iHub app. Get the app here: https://marketplace.atlassian.com/1220905

Synchronizing new issues from Jira A to Jira B

Start by installing iHub from the Atlassian Marketplace.

This is what we want to accomplish:

  • All Jira issues, in a project, that are created in "Jira A" shall be synchronized to "Jira B" and vice versa.
  • Synced issues shall be back referenced in "Jira A" for future tracking. (see syncing everything below)

Setup in Jira A: Authentications

First, create authentication for Jira B access.

The iHub has support for

  • Oauth2 (with support for authorization code, implicit, resource owner password, client credentials, and authorization code with assertion)
  • Basic auth
  • Bearer tokens

Here, we're creating a basic auth for accessing the Jira B instance. Authentications are reusable and can be used for multiple integration actions.

Integration configuration

Next, set up the configurations for syncing Jira A to Jira B.

Setting up integrations is easy, it's a no-code, user-friendly interface.

The iHub talks REST. We're using Jiras REST API to synchronize new issues to Jira B-instance.

  1. Select HTTP method POST and enter the Jira B instance URL followed by /rest/api/2/create which is the Jira API endpoint for creating issues. (For convenience, iHub has templates that fill this in for you)
  2. Select the authentication created in the previous step, here it's JIRA B User[BASIC_AUTH]

Note: Make sure that the HTTP Headers have Content-Type set to application/json, if not, just add it manually.

3. Fill in the fields that you want to set in the Jira B synched issue. Read more about the Jira API here: https://docs.atlassian.com/software/jira/docs/api/REST/8.8.1/

Note how we access variables by using for the Mustache expression {{ issue }} This will get you access to the issue within this scope. (scope = issue that triggered this integration to run)

Access issue properties like this {{issue.summary}} to get the summary. {{issue.issueType.name}} to get the issue type name. All this is documented here: https://doc.rixter.se/display/RIFJ/

Trigger configuration

For the synchronization to happen we need to set up a trigger. In this case, we will listen to all issue created events.

  1. Select "Issue Created" in the event triggers list. This will trigger this integration every time a new issue is created.
  2. Add a JQL condition to narrow the scope on which issues that are synced, or leave blank to sync everything. In this example were only synchronizing the project "SYNCIT"

That's it! Now all new issues in Jira A that are created in project SYNCIT will be posted to Jira B.

Saving issue key from Jira B

Since we most likely want to synchronize issue updates, comments, i.e. we need to store the issue key from the newly created issue in Jira B.

This is the response from the Jira B create issue API

Now, let's use this and update the triggering issue with the key from this response. This is done by creating a "child action".

A "child action" can use the response from its parent and do what it needs with it. It gets triggered after the parent has been triggered.

Create a new action, let's call SYNC - Set Reference

1. Select the "Auto-generate 1st level as variables from response". This will make the first level of json response available as variables.

In this example: id, key, self will be accessible by using Mustache templates ie. {{ key }}.

( If you need variables further down the json response you can specify a json path manually to get hold of that variable. )

2. Fill in the URL details, in this example, we're updating our parent issue using the Jira REST API.

HTTP method PUT, the URL is {{baseUrl}} /rest/api/2/issue/{{issue.key}}

3. Select an authentication that has access to Jira A (If no one exists, create one following the steps above)

5. Fill in the PUT body. Here we're using the {{ key }} variable auto-generated from 1 above.

That's it!

Now you're all set for synchronizing two Jira instances.

If you need advice on how to sync comments, updates, and transitions please feel free to reach out to us.

Get the app here: https://marketplace.atlassian.com/1220905

This will be the first article in a series of articles on how to integrate Jira with other systems in less than 5 minutes.

I know that 5 minutes is not much, but if you have your ServiceNow instance up and running and know how to setup Oauth2 applications in ServiceNow you can do this in less than 3 minutes!

First, get the Jira app, "Integrations Hub for Jira" Get it here: https://marketplace.atlassian.com/1220905

Second, create an Oauth2 connection to ServiceNow

  • In ServiceNow, create an Oauth2 application. Never done this before? Just follow our guide here: https://doc.rixter.se/display/RIFJ/ServiceNow It's easy-peasy!
  • Now click the "lock" icon in the icon-menu, enter a name and click "Add authentication"

  • Select Authorization code and fill in your client id, secret ie.

Third, now create an integration action that uses this Oauth2 client to create a ServiceNow incident.

  • Click the "Create" button to create a new Integrations Hub for Jira action.

  • Fill in the form that pops up, use template "default" and content-type "application/json"

  • Fill in the integration details such as ServiceNow URL

  • The body section contains the POST body that goes to ServiceNow. In this example, we're posting the Jira Issues summary and description to ServiceNow. Read up on the full list of variables that can be used here: https://doc.rixter.se/display/RIFJ/User+Guide

And finally, set up how to trigger this integration.

  • Triggering an integration can be done in many various ways. Such as, a Jira event, schedule a cron job that runs this on a scheduled basis. From the post functions section, create a post-function or set up an incoming request rule that triggers this integration.
  • In this case, we have chosen to trigger this for all newly created Jira issues

Now, test your integration by creating a new Jira issue!

Happy hacking!

With our latest release of REST Integrations & Automations, it is super simple to create any OAuth integration without needing to code!

In this tutorial, I will describe how to do it with salesforce and some of the use cases that we see are common.

So we want to achieve this:

When an issue is created it sends that to Salesforce and updates the issue with the case number and status.

Secondly, we want to fetch the status of the case to find out if there has been any update. 

This can also be done on a periodic schedule by using the cron expression. (not covered in this article)

So were do we start?...

The first thing that needs to be done is to create what Salesforce calls a Connected app.

The important thing here is to select the right scope and to add the callback URL. This is always found on the OAuth authentication page in RINT.

Once this is done the next step is to set up the authentication in RINT.

In RINT we select the Authentication menu (lock icon) and enter the details that out Salesforce connected app returned. 

Note that state shall be check but leave the scope blank.

Once all the data is filled in click Authenticate and login to Salesforce. You will notice the two labels "Auth Code Granted" and "Access Token Granted" when all went good.

So now down to the actual REST call to do something in Salesforce based on JIRA data

Simply click Create and fill in a name and select the application / json as template to get the headers for free.

The request details can now be filled in, such as the method and url. Note for salesforce use the "instance.salesforce.com/...." as url and not the force.com.

Now to where the actual JIRA data comes from

The body part of the form describes what data to send, RINT can send the issue data by simply using curly brackets and dot notation.




Trigger Time!

Once the data for the REST call is setup the only thing left is to add a Trigger to decide when to send the call.

We will use Issue Created with the condition limited to our SAL project.

This now means that the REST call to salesforce using the authentication that we setup will be triggered every time there is a new issue in our SAL project!

Yeah! but wait... how does it know to update the issue with the Case ID?

Now the chained actions come into play.

We will create a new action again this time we will use the "Select parent action" field to specify our previously created "Salesforce - Add case info"

Further on we can take some help by selecting the "JIRA Core Server" category and the "Edit Issue" template to speed things up.


What did we get now?

First, we can see that the tree now has a parent → Child for the salesforce part. Secondly, we can see that it created a new REST request to our JIRA server.

By selecting "Auto-generate 1st level as variables from parent response" we will automatically on this REST call get the response from the create case call as variables.

The response can be viewed by clicking on the Execution log on the "Salesforce - Add case info" action

So let's use what we know from the response to send that to the edit issue REST call.

As noted the {{id}} will automatically be replaced by the response from the parent once the chain is executed.

Inbox new feature teaser!

Can you spot the new Inbox for JIRA feature?

Are you switching between your mailbox and JIRA to keep up to date with what is happening?

Are you feeling that important issues are some times missed out?

Time to change that!

According to different studies, context switching can eat up to 40-80% of your productive time!!!

With Inbox for JIRA you can increase your productivity and remove the barriers by adding in-app notifications!

Inbox is located next to your avatar and is shown as a bell.

Get it today at Atlassian Marketplace Inbox for JIRA





There's a new add-on in town! "REST integrations and automation for Jira" made by the add-on vendor Rixter.

REST integrations and automation for Jira enables custom made, no-code trigger-driven rest-integrations and automation.

During the engineering research, people have said: "This is the missing piece we've been looking for!".

So, what's the fuzz all about?

This addon gives you the power to create REST integrations and automation from an intuitive UI; no-code and scriptless. Triggered by an issue event or on a scheduled basis, all in the world of REST API's.

All your REST-integrations aka. "actions" can be chained, using the response from one as input to the next. Hence, the possibilities are endless!

The fact that Jira is exposing a REST API's this becomes extremely powerful, you can now automate your Jira instance in any way you want.

REST integrations and automation for Jira can be found at the Atlassian marketplace. Click here to Get it now!

Read more: https://doc.rixter.se/display/RIFJ/

Happy integrations!