Confluence has been updated to version 6.15.9




Last week we got a request from one of our prospects.  They were looking to connect an external facing service desk with an internal development JIRA.  The external JIRA is configured with a single service desk configuration - providing generic request types such as 'Raise a problem', 'Submit an idea' ... Some of these requests need to be escalated to the internal development JIRA and kept in sync such that the support engineer can keep in touch with the customer whenever development has a couple of questions or whenever a fix is made available.


The result


Keep it simple


The case has 30 different products under development.  We wanted to avoid that customers had to select the right service desk to raise tickets because it is not very nice for the customers to have them to browse through different categories, and if they do, they are not always right so we have to recategorize regularly and lastly the service desk is integrated with email - requiring to categorize anyway. Instead of complicating raising issues for the customer we decided that we wanted a very simple UI for the customer, providing just 2 options


Raising an issue is not harder than entering an email


Simple isn't it ?



Involve development


Support engineers are there to support.  They are great at keeping the customer informed and handling all customer concerns, but some of these issues are nasty and need to be addressed by development.  There should be a way to dispatch an issue to another team - who can do their magic and provide a fix (or workaround) for the problem.  


Adapt the workflow

First of all we needed a way to track the issue when it is assigned to development, so we changed the standard development workflow by adding a status 'Waiting for development' and adding a couple of transitions

  • Escalate transitions the issue from 'Waiting for support' or 'Waiting for customer' to 'Waiting for development' indicating that development is working on it
  • Dev done transitions the issue from 'Waiting for development' to 'Waiting for support' so that the support team can communicate to the customer they can give it a try.




What team should handle the problem ?

A support issue can be raised against 30 different products, so there should be a way to categorize the issue such that the appropriate team is notified about the request and start handling it.  We therefore added a simple drop down list, listing all the potential products.   When an issue is escalated to development, the support engineer can provide his assessment in what product and at what priority the problem should be handled.


Delegating to another project on another issue tracker


For security reasons, the service desk environment is hosted on another JIRA than the development JIRA.  We didn't want to expose the internal development information to the internet.  A configuration is easily made, risking to make IP sensitive information available.  





When a support engineer escalates a customer request to development - the request should be copied over to the development JIRA (in the right project !) and all information must be kept in sync. Development needs to know which customer has raised the issue, it must be possible to request additional information (such as log files or screenshots), and support must work with the customer once that the issue is resolved.




Configuring relations

Enter Exalate - the flexible JIRA Synchronisation solution. 
Check the 'Setup your first synchronization between 2 JIRA Servers' for the details to setup the synchronization between the two instances, but at a certain stage of the configuration it is necessary to configure the synchronisation such that the new issues get created in the appropriate development project.  Exalate provides its flexibilty through scripts and a very open object model.  For the techies - check out the Issue fields available for synchronization which details out what objects and fields are available when a message is being processed.

To ensure that the customer request is raising an issue in the appropriate project, we configured the create processor on the development server to look up the project


def targetProject = replica.customFields.product?.value?.value
def project = nodeHelper.getProjectByName(targetProject)
// if the project is not found use the default project (General)
if (project == null) {
   issue.projectKey = "GEN"

That's it - when a new development project is created, it is sufficient to add the name of the project to the drop down.  No additional configuration is necessary.