In one of jsm project organization fields are getting populated on the basis of reporter email address.Same organization field not working for other jsm project.There is no.project automation, form present.
Hi Gurinder,
Can you provide some more details? What exactly is happening and what should it be doing?
In one of my JSM projects, whenever a customer creates a Jira issue, the Organization field is automatically populated with the reporter’s organization.
I checked the project configuration and could not find any automation or form that is responsible for populating the Organization field based on the reporter/requestor’s email address.
My understanding is that JSM may be automatically identifying the organization based on the customer-to-organization membership—i.e., if a customer belongs to an organization, JSM automatically updates the Organization field with that organization.
However, I am now working with another JSM project where I am using the same Organization field, but this behavior is not occurring. The Organization field remains blank even though the reporter/customer belongs to an organization.
Why does this work automatically in one JSM project but not in the other? Is there any project-level or global configuration that controls this native behavior?
Gotcha. It might be that the Organization has not actually been added to the second project. Go to Space Settings > Customers >Add organization
I checked the project configuration and could not find any automation, form, or other project-level automation responsible for populating the Organization field based on the reporter/requestor’s email address.
However, I noticed a difference between my two projects:
Both projects use the Organization field, and there is no automation or form configured to perform this mapping.
Why does this native behavior work in a Service Management project but not in a Customer Service Management project? Is there any CSM-specific configuration, limitation, or setting that controls automatic organization assignment based on the reporter/customer?
@Gurinder Summan I use an automation and some API calls. When a new Service Request is submitted, it uses an API call to get the Organization assigned to the Reporter. Then it stores that value and adds it to the work item. You could try that.
I had Atlassian Support help with the syntax, especially with the API calls, but that might be an option to try.
But if Organization isn't available in CSM (Per CSM-163), yeah, that's not going to work.
Hello @Gurinder Summan ,
@John Funk and @Marc -Devoteam- have identified the core of it: the two projects behave differently by design. Your Project 1 uses the classic Service Management template, where the Organizations concept auto-associates the reporter's organization. Your Project 2 uses the Customer Service Management (CSM) template, which handles organizations through a different model entirely, so the classic auto-populate behaviour is not there to configure, exactly as Marc says.
Since you asked for a direction, here is the actual decision in front of you:
Option 1: stay on CSM and use its organization model. In CSM, organizations are profile entities, each with its own profile page and detail fields, and the customer's organization membership provides context on requests rather than writing the classic Organizations field. The practical payoff: those organization detail fields work in JQL, so you can build queues, SLAs, reports and automation keyed to the organization without the field ever being set on the work item. If your goal is "agents and queues should know which organization a request belongs to," CSM can meet it, just through profiles and JQL rather than a field value. The customer and organization management docs cover the pieces: https://support.atlassian.com/jira-service-management-cloud/docs/manage-your-customers-and-organizations/
Option 2: if the classic Organizations field behaviour is a hard requirement, for example existing reports or automation keyed to that specific field, then the honest answer is to run that workstream on a classic Service Management project, like your Project 1, since that is where the behaviour lives. Your own site proves this works today.
One reassurance if you ever consolidate: Atlassian's migration documentation confirms that existing customer and organization profiles carry over automatically when moving between Jira Service Management and Customer Service Management, so choosing one direction now does not strand your organization data: https://support.atlassian.com/customer-service-management/docs/move-from-jira-service-management-to-customer-service-management/
The deciding question is simple: do you need the organization as a field value on the work item, or as context your team can see and query? If it is the second, stay with CSM and build your queues on organization details. If it is the first, the classic template is the right home for that project.
It looks like you're new here. Sign in or register to get started.
