Import Customers and Organizations into Jira and Jira Service Management in 2026: A Practical Guide

[#1]

“Import customers into Jira” sounds like a single task. In the Atlassian ecosystem, it is not. What you can import, what gets created, and where that data is usable depends on which product actually owns the customer model in your site.

Atlassian currently spreads “customer” concepts across three layers:

• Jira Core (Jira Software / Jira Work Management): no customer model at all
• Jira Service Management (JSM): customers as service-facing identities, with import focused on updating existing records (on sites that still have the feature)
• Customer Service Management (CSM): customers and organizations as profiles designed for external customer support, with bulk import supported, but scoped to the CSM system and its usage model
  
  

The rest of this article walks through those layers in order, with concrete import behaviors and the structural implications that show up after import “works.”

Jira Core and the Absence of a Customer Data Model

Jira Core’s primary object is the issue. Everything you manage is either an issue, a field on an issue, or a relationship between issues and users/projects. There is no first-class system entity that behaves like “Customer” or “Organization” as a reusable record.

That distinction is not terminology. It determines whether Jira can enforce identity and reuse. If a “customer” is represented as text in a field (for example, Customer Name), Jira can store it, but Jira cannot guarantee uniqueness, model relationships, or build a customer history across projects without you reconstructing it from issues later.

At this point, the limitation is not one of configuration but of system scope. Once a team needs customers as persistent records with identity, relationships, and history, they are effectively operating in CRM territory rather than in work management territory. Jira Core itself is not designed to provide that layer, which is why teams that want customer records inside Jira typically introduce a Jira-native CRM solution, such as Mria CRM: CRM for Jira Teams, where Leads, Deals, Contacts and Companies exist as first-class objects instead of issue metadata.

Import Customers in Jira Core (Not Supported)

Because Jira Core has no customer entity, it cannot import customers as customers. The only thing a CSV import can create or update is issues and issue fields. That means any “customer import” in Jira Core becomes one of these patterns:

• bulk-creating issues where each row is a customer (which turns customers into work items, not records), or
• bulk-updating fields on existing issues (which spreads customer data across issues)

Both patterns are workable for lightweight tracking, but they do not create a customer directory with stable identity, company relationships, or customer history that is independent of issue structure.

Jira Service Management and Service-Based Customers

Jira Service Management introduces customers and organizations primarily to support service workflows: request submission, communication, visibility, and agent context. In this model, “customer” is fundamentally a service interaction identity, not a CRM record.

That design choice explains why JSM historically focused on portal behavior and ticket context rather than on building a globally reusable customer directory across Jira.

Product Boundary Change Introduced in October 2025

In October 2025, Atlassian changed the product boundary: customer service features are no longer available in Jira Service Management on new sites. Atlassian states that instances created before Oct 10, 2025 can still access those features within JSM, while new sites must use the Customer Service Management app (included in Service Collection).

This matters because many “how do I import customers into JSM” questions are really two different situations:

• sites that still have customer/organization profile features in JSM
• sites that do not, because those features moved to CSM

Import Customers & Organizations in Jira Service Management

On eligible JSM sites where customer/organization features exist, Atlassian provides an import flow titled “Import customer and organization details through API or CSV.” The key word is details. Atlassian explicitly states that this import:

• imports values into fields that already exist
• will not add new fields
• will not import new customers or organizations

What this import is designed to do

This is a profile enrichment mechanism. It is appropriate when your customers already exist as service identities and you want to populate structured details (for example, region, tier, phone, contract ID) using custom detail fields you created beforehand.

Concrete mechanics and constraints (real operational details)

The CSV flow has hard limits:

• 1,000 rows per file
• 1 MB maximum size per file
• larger datasets must be split across multiple imports
  
  

The identifier requirements are also strict:

• for customers: Email column header required
• for organizations: Organization Name column header required
• other columns must exactly match existing customer detail field names, otherwise they are ignored

The UI path is also service-project anchored (not Jira-global).

The official step-by-step instructions are available in Atlassian’s documentation: https://support.atlassian.com/jira-service-management-cloud/docs/import-customer-and-organization-details/ 

The structural consequence

Even if you enrich details successfully, the underlying model remains service-driven. You end up with better service profiles, but you still do not have a customer data layer that behaves like Jira work data across Jira Software projects. That becomes visible when teams try to reuse customer identity across engineering issues, delivery tasks, and multiple service projects without duplication.

Customer Service Management and Service Collection

Customer Service Management (CSM) is where Atlassian consolidated customer service features for new sites after the October 2025 boundary change. Atlassian describes this explicitly and positions CSM as the destination for those features going forward.

CSM matters for import because it is the first Atlassian-native place where bulk import is framed as a primary workflow for building customer and organization profiles.

Import Customers & Organizations in Customer Service Management

CSM supports importing customer and organization profiles using CSV or REST API and explicitly describes the ability to import profiles in bulk.

Concrete mechanics and constraints

CSM CSV import requirements include:

• each row represents a single customer or organization
• each file up to 50,000 rows
• each file up to 80 MB
• file must be UTF-8 encoded
  
  

Column header rules are similar in spirit but applied to the CSM profile system:

• customers: Email required
• organizations: Organization Name required
• other columns must match your existing customer/organization detail field names
• fields must be created before import; unknown headers are ignored

CSM also documents an important compatibility caveat for teams coming from older profile behavior: if you previously used customer and organization profiles on Jira Service Management, imports may inherit the older small limits (1,000 rows / 1 MB) and require profiles/fields to already exist in that legacy context.

Relationship handling during import

Although CSM allows importing customers and organizations in bulk, relationships between customers and organizations are not imported as part of the CSV import process.

In practice, this means:

• customer profiles are created or updated
• organization profiles are created or updated
• but the system does not establish membership relationships between them during import
  
  

After import, customers must be manually assigned to organizations through the CSM interface or via additional API operations. There is no native mechanism to define customer–organization relationships directly inside the CSV file in a single import step.

This has an important operational implication: even when customer and organization datasets already exist in an external system with a well-defined relational structure, that structure is not preserved during CSM import and must be reconstructed manually inside Atlassian.

What import “creates” in practice

CSM import creates CSM customer profiles and organization profiles. These profiles are designed for customer support operations: agent context, entitlement-style attributes, and customer-facing service workflows. The system is stronger at onboarding customer profiles than JSM’s details-only import, but the model remains a customer service subsystem rather than a Jira-wide entity model.

Atlassian’s official documentation for CSM customer and organization import is available here: https://support.atlassian.com/customer-service-management/docs/import-customer-and-organization-profiles/ 

Structural Limitations of Atlassian’s Native Customer Model

Atlassian’s Customer Service Management solves a real problem: external customer support needs customer context. But it is still important to understand what kind of “customer object” CSM provides, because that determines what teams can do after import.

Customers Are Not System-Level Jira Objects

In Jira, system-level objects (like issues) participate directly in core mechanics: workflows, permissions, indexing, automation triggers, and reporting structures. CSM customer profiles exist primarily to support customer service experiences. Even when they are rich in fields, they do not automatically become a universal “customer dimension” that every Jira team can use in the same way they use project, issue type, or component.

The practical symptom is that teams can successfully import profiles and still struggle to make customer identity a first-class driver of cross-project processes. Import may be complete, but reuse outside the CSM context remains bounded by product architecture.

Customer Relationships Are Structurally Limited

CSM supports customers and organizations and allows assigning customers to organizations. That is a useful baseline for support. In B2B environments, however, teams often need a relationship model that goes beyond “customer belongs to organization,” such as:

• multiple companies per contact (contractors, partners, multi-entity stakeholders)
• parent-child company structures
• role-based relationships (billing contact, technical sponsor, procurement)

If the relationship model is narrow, teams end up encoding relationship meaning in text fields, tags, or external systems. That reintroduces fragmentation after import because the relationships are no longer enforced as structure.

Import Is Profile Enrichment, Not Data Modeling

CSM import is powerful at onboarding profiles and populating profile fields, but it does not turn Jira into a general customer data model where teams define entity types and relationship semantics in the way a CRM would. That does not make CSM “bad.” It makes it specific: a customer service profile system, not a general-purpose customer data layer.

This difference is the main reason teams can be satisfied with CSM for customer support while still searching for “CRM in Jira” or “customer directory in Jira” for broader operational needs.

Adoption Implications of Customer Service Management

Even when Customer Service Management is conceptually the right model for a team, adoption is constrained by how it is packaged and licensed, because CSM is not a standalone capability. It exists only within Atlassian Service Collection, which means that introducing customer profiles through CSM is not a simple feature decision, but a broader platform adoption decision that affects system scope, roles, and operational boundaries.

Service Collection as a Product and Pricing Boundary

Atlassian Service Collection is positioned as a bundled platform for service management and customer service, rather than as a modular set of independent components. Customer Service Management is delivered as part of this bundle, together with other service-related capabilities.

This boundary is important because “we need customer profiles in Jira” is often a much narrower requirement than “we want to adopt a full service management platform.” When customer functionality is only available inside a bundle, teams cannot adopt it in isolation. The scope of the solution expands beyond customer data into a broader service ecosystem, which may exceed the original problem the team is trying to solve.

CSM Is Only Available Inside Service Collection

Customer Service Management cannot be licensed or enabled independently. Teams cannot purchase or deploy “just CSM” in the same way they might adopt a Marketplace app or a standalone Jira app like Jira Service Management.

As a result, adopting CSM implicitly means adopting the entire Service Collection product set and its operating model. This can lead to situations where teams introduce additional tooling and capabilities that are not directly related to their need for structured customer data, simply because customer profiles are locked inside a bundled product.

Agent-Based Pricing and Product Bundle Implications

Service Collection follows an agent-based pricing model, which scopes access to customer profiles based on who is licensed as an agent within the service platform.

This has direct implications for how customer data can be used across the organization. Customer context is rarely needed only by support agents. It is often required by engineering, product, delivery, and account teams as well. When customer data lives inside an agent-scoped system, organizations must either restrict access to customer records or extend agent licensing to roles that are not primarily service agents.

In practice, this creates friction between how broadly customer data is needed and how narrowly the system is licensed. Instead of behaving like shared operational data inside Jira, customer records remain tied to a specific role model and pricing structure, which limits their ability to function as a general customer data layer across teams.

Mria Contacts: Introducing a Customer Data Layer Inside Jira

Mria Contacts: Contact Management in Jira & JSM by Mria Labs approaches the problem from a different premise: customers and companies should exist as business records inside Jira, independent of service request identities and independent of which Jira project a request originated from.

The goal is not to replace a service portal model. The goal is to create a stable customer directory that can be linked to work across Jira Software and Jira Service Management.

Contacts and Companies as System-Level Entities

Mria Contacts introduces two entity types: Contact and Company. These are not portal users and not support profiles. They are customer records maintained as structured objects that can be referenced across projects and issue types.

The structural implication is reuse: the same Contact and Company record can be linked to multiple Jira issues and multiple JSM tickets without duplicating the customer identity in each place. That shifts customer data from “fields on work” to “records linked to work.”

Customer Profiles and Relationship Model

Mria Contacts provides full profile views for Contacts and Companies with structured fields, related work items and notes. The relationship model is explicit and bidirectional:

• Contact can be related/linked to one Company
• Company can have multiple related/linked Contacts

That relationship structure is what allows account-level history and stakeholder-level history to coexist. It is also what makes import meaningful beyond “details,” because the system can preserve relationship structure rather than forcing teams to rebuild it manually.

Linked Work Items and Customer History

Contacts and Companies can be linked to Jira issues in any project and to JSM tickets. Those links are surfaced back on the Contact/Company profile as “Linked work items,” creating a customer history that spans support, engineering, and delivery work.

In Mria Contacts, Contacts and Companies can be linked not only to Jira issues and JSM tickets, but also to Confluence pages and spaces.

In practical terms, this means that customer-related documentation can be associated directly with a customer record. For example, onboarding guides, implementation notes, contracts, or meeting summaries stored in Confluence can be linked to the relevant Contact or Company.

These links are visible inside the Contact and Company profile under linked work items, alongside Jira issues and tickets. In this model, those links are not “attachments.” They become part of the customer record’s knowledge graph: customer record → related work → related documentation.

Permissions and Customer Data Governance

Mria Contacts includes permission settings so admins can control who can view, edit, or administer customer records, including visibility of customer data in issues/tickets. Governance is not a bonus feature here; it is required if customer records are going to be reused broadly across teams without becoming uncontrolled.

Customer Import in Mria Contacts as Data Modeling

This is where the model difference becomes concrete: import is not “populate fields on profiles that already exist.” It is “onboard a customer dataset as entities and relationships.”

One-File Import for Contacts, Companies, and Relationships

Mria Contacts supports importing Contacts and Companies together in a single file and creating the relationships between them automatically. That matters because real customer data is relational. Importing contacts without companies, or companies without their contacts, typically produces a directory that is correct but not usable.

The output is a structured customer graph: contacts exist, companies exist, and relationships exist immediately after import.

Re-Import for Synchronization and Enrichment

Mria Contacts supports re-importing updated files to overwrite values or add missing information. This turns import into a repeatable synchronization mechanism rather than a one-off migration step. That is important because customer data changes constantly, and teams need a way to correct and enrich records without breaking work history links.

Using Mria Contacts in Jira Workflows

This section is about operational behavior: where the customer data appears, how it is linked, and what workflows it supports.

Customer Linking in Jira Software Issues

From a Jira issue, the Mria Contacts panel allows users to search and link multiple Contacts and Companies to the issue. Once linked, those records are visible on the issue, and the issue appears in the Contact and Company profile’s linked work items.

The structural impact is that customer identity becomes explicit and queryable across engineering work, rather than being implied by text fields or external systems.

Automatic Customer Detection in Jira Service Management

This workflow introduces identity resolution at ticket creation time. When a request is raised in Jira Service Management, the Mria Contacts panel checks whether the requester matches an existing Contact record and whether the requester’s Company already exists in the system.

If matching records are found, the system suggests linking them immediately. If no records are found, the system suggests creating a new Contact and Company record directly from the ticket context.

The reason this matters is data integrity, not convenience. Identity resolution at the point of entry is how customer directories stay consistent over time, especially in environments with multiple agents, multiple communication channels, and repeated customer interactions.

Manual Customer Linking and Identity Resolution

Manual linking is still required for common support patterns: proxy requests, shared inboxes, partner-submitted tickets, or cases where the requester is not the primary stakeholder. Mria Contacts supports searching and linking contacts/companies from the ticket panel, and all linked tickets appear in the customer profile.

The operational result is that customer history is maintained based on the customer entities linked to the ticket, not merely on the requester identity.

Practical Use Cases for Customer Data in Jira

1. Unified customer context across Jira Service Management and Jira Software

Support requests often start in Jira Service Management but continue as work in Jira Software: escalations, bugs, follow-ups, delivery tasks, or internal coordination.

With Mria Contacts, the same Contact and Company records are linked to both JSM requests and Jira issues. This creates a continuous customer context across support and engineering, so customer identity does not get lost when work moves between teams or tools.

2. Account-level view for B2B customers

In B2B environments, multiple people from the same company interact with Jira over time: technical users, managers, procurement, partners.

Mria Contacts allows all individual Contacts to be linked to a single Company record. All Jira issues and JSM tickets related to those people accumulate under the same Company profile, creating a real account-level view inside Jira.

3. Customer onboarding and delivery tracking

Many teams manage onboarding, implementation, or customer delivery work in Jira projects.

Mria Contacts allows onboarding tasks, delivery issues, and related Confluence documentation to be linked directly to the customer record. This makes it possible to see all onboarding and delivery work for a customer in one place, even after projects are closed or archived.

4. Centralized customer history across projects

Over time, customer-related work is spread across multiple Jira projects: service desks, engineering projects, internal initiatives.

Mria Contacts provides a centralized customer record where all related issues and requests are visible, regardless of which project they belong to. This creates a persistent customer history that survives project and team changes.

5. Reliable customer identification in support workflows

In Jira Service Management, customer identity is usually limited to the requester’s email address.

Mria Contacts automatically identifies existing contacts and companies when requests are created and allows agents to link or create records directly from the ticket. This ensures that customer data stays consistent and that new work is always connected to the correct customer records.

Conclusion

Customer import in Jira only makes sense once you understand where customer data actually exists in your setup. 

• Jira Core does not have customer entities at all, so it cannot import customers as records.
• Jira Service Management sites created before October 10, 2025 (before the introduction of Atlassian Service Collection) can import customer and organization details, but only to update profiles that already exist as service identities, not to create a customer dataset. 
• Customer Service Management supports bulk creation of customer and organization profiles, but these remain part of a customer support system available only through Service Collection and do not preserve customer–company relationships during import. 

If your use case requires structured Contact and Company management inside Jira, with reliable customer context across Jira Service Management and Jira projects, you can try Mria Contacts directly from the Atlassian Marketplace.

For a complete walkthrough of how Mria Contacts works in practice, including customer identification in JSM requests, linking contacts and companies to issues, and viewing consolidated customer history, you can also watch the full demo video.