Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

4 little tricks to enhance Jira workflow with LDAP data


Every company looks for ways to improve their workflow and avoid any delays. Especially big corporations where is so many people that it’s easier to manage the most complex management tool than to remember everyone’s names. However, a great workflow without bottlenecks is often created by implementing small, but tremendously helpful tricks. Even simple automation of some administrative activities can greatly affect company’s processes. One possible way is to provide a tighter connection between Jira and the LDAP server like Active Directory.

Connecting Jira to LDAP

Active Directory uses a domain structure to contain and organise information about shared resources such as servers, volumes, printers and accounts: users, groups and computers. It stores information such as names, passwords, phone numbers, etc., and makes it searchable. Then, web applications can use LDAP, or Lightweight Directory Access Protocol, to look up this information. There are a few LDAP servers on the market, and fortunately Jira provides built-in connectors for the most popular ones, such as Microsoft Active Directory, Apache Directory Server, Fedora Directory Server and a bunch of others. There is a step-by-step guide to est ablishing LDAP connection on the Atlassian documentation.

Even though we can integrate Jira with Active Directory natively, the default integration doesn’t enable the synchronization of users’ attributes. Of course, we can import their accounts manually, but it’s much easier to synchronize user data automatically. Active Directory Attributes Sync is one of the apps available on Atlassian Marketplace that enable advanced use of LDAP data in Jira. With the app installed, we can display users’ attributes in a couple of places, as well as perform some actions on the LDAP server with no need to wake up the admin.


Active Directory Attributes Sync architecture includes synchronizing LDAP with Jira and advanced workflow post functions 

Advanced use of Active Directory data in Jira

Automated Active Directory account management

Sometimes, big companies struggle with onboarding a new employee right away on their first day at work. In most cases, it’s not caused by unprepared working space or hardware, but rather by admin-related tasks like creating new users in the database, granting permissions, and so on, because Active Directory admin needs to take care of this and not Jira admin or even a project admin. However, it’s possible for us to deal with this automatically – we can add the Update Data post function to our workflow to automate creating a user account in Active Directory when creating an onboarding task.

Moreover, we can select other options to update and manage Active Directory user data from the Jira instance. Probably all of us set various passwords for different accounts, which makes it easier to type in the wrong one when logging in at work before we have the first coffee in the morning. We can ask the Active Directory admin to reset our password, but we can also simply create a Reset Password task in Jira which will trigger the same post function configured differently. The password will be automatically stored in a custom field which we recommend to set as Secureand when the task is In Progress, this post function will also unlock the user in Active Directory. This way, we get a new password and can log in again almost immediately.

The same goes for changing user’s attributes like Email, Job Title, Phone Number, etc., as well as removing users from the Active Directory or managing group memberships. Each of these actions can be done with a different setup of the same post function. This way, we don’t have to worry about how changes in the company will impact our work, because we’ll be able to create a Service Desk issue with the specific value we need to change that will trigger an automated update of the specified attribute in both Jira and Active Directory. The Update Data post function also automates removing users and adding them to groups by simply making transitions of the right Service Desk issues that will either automatically give permissions to a user or take them off the list. (1).gif

Employees’ information at hand

Once we synchronized Active Directory with Jira, we can display some information about our employees not only in their public profile or hover dialogue but also on the issue view and Customer Portal. It comes in handy when we want to provide our customers with another way of communication with the agents because we can show them an agent’s email address or even phone number. The same goes for dealing with internal issues when the employees can simply check out who’s taking care of their requests and reach out to an assignee outside the company’s Service Desk.


What’s more, we can also add an agent’s supervisor to their requests by adding another post function Copy Property to the workflow. Thanks to this, a manager will be able to have an eye on what their subordinates are dealing with, and their information will also show up on Customer Portal or the issue view in a dedicated custom field.

Advanced Jira approvals

We can use synchronized data not only in case of some administrative actions but also to use advanced conditions. One of them protects us from executing requests by our agents that are costly for the company. For example, if only managing staff can request more expensive gear or 5-star hotel bookings, we can require acceptance from the top management, and no one else can push these tasks forward. We only need to set up the manager’s attribute from Active Directory as the Approver, and such requests will need approval from the higher-ups. And in case if a manager leaves the company and is replaced by a new one, this condition automatically updates the configuration.

Search for issues by Active Directory attributes

Another little trick helps us search issues for attributes synchronized from the Active Directory server. Whenever we need to find a custom field, reporter or assignee, we only need to specify a JQL query by providing three arguments: custom field/reporter/assignee, an attribute, and its value. For example, when we’re looking for a developer who works in the company’s office in San Francisco, we provide such a query:

issue in searchFromAD(“Developer”,”City”,”San Francisco”)

Trick or treat for a workflow?

It’s not Halloween and we don’t need to ask ourselves those questions, but it still fits in this situation. Making use of the synchronized data from our Active Directory is both a trick for us and a treat for our workflow to make work seamless and allow more effective communication.

If you’d like to learn more about Active Directory Attribute Sync, watch the tutorial to know 10 best ways to make it work for your company. You can also book a live demo via Calendly, if you’d like to see the app in action, or read more on the subject:



Log in or Sign up to comment
Dzmitry Hryb _Deviniti_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
February 22, 2018

Which other options to make use of LDAP data in Jira can you see?

Craig Castle-Mead
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 3, 2018

Hi @Dzmitry Hryb _Deviniti_ - I definitely agree that having your Atlassian suite tied to the companies backend user directory (AD or otherwise) is ideal. With integration between hiring workflows and AD, this is an even bigger win as it's end-to-end, however depending on how your company is structured (say your IT department is "lean", run in a different timezone, or outsourced) and user creations may not be done in the most timely manner, staff may push to have local users just cause they're "quicker". Recommend admins stand firm with requests like this as even if it's a small hassle up front to get the user created in AD first, the benefits of same sign on with other tools, correctly managed leavers processes among others.


From a compliance point of view, having environments like this tied to AD etc help with security audits as the burden of proof to show that you're correctly exiting users if they leave the company is much lower.



Dzmitry Hryb _Deviniti_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
March 5, 2018

Hi @Craig Castle-Mead. Surely there is a little legwork with configuring the sync and creating the users in Jira, but you do it just once - after this, you have access to all the goodness that the app provides, and automate user creation in AD using the Update Property post function, if you need it.

Like Justin_Bailey likes this
Gideon Gabriel
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
January 22, 2020

Hi @Dzmitry Hryb _Deviniti_ we just recently migrated to JIRA Cloud and I have been told by our Service Desk people that we can no longer see the Reporter's Location / Department etc. as apparently the JIRA Cloud cannot pick this up from our on premise Active Directory … Our service desk people told me that, when we used JIRA in its on-prem form we used an Add-On from your company, but that you don't have an add-on that works with JIRA Cloud... Is this correct?
I am hoping not as this functionality was crucial in helping us manage our queues...

AUG Leaders

Atlassian Community Events