Permissions in a traditional external CRM are usually built around the sales organization. Sales representatives, managers, and administrators receive different levels of access within a system used primarily by sales.
CRM in Jira requires a broader permissions model.
Customer-related work already extends across teams in Jira:
- Support needs to know who submitted a request, review previous interactions, and understand whether an active Deal or existing customer relationship is involved.
- Development needs to see which customers are affected by a bug or dependency behind a Jira item.
- Product teams need to know which Contacts and Companies requested a feature and which Products or Deals are connected to it.
- Delivery needs the Company, stakeholders, Deal, and previous history behind implementation work.
- Finance may need to review closed-won Deals, amounts, Companies, Products, and related Contacts to prepare invoicing data and reconcile revenue. It may also need access to reports for forecasting, without permission to create Leads or change sales processes.
Mria CRM is designed to make the customer and the work related to that customer shared across these teams within Jira. Making this context shared still requires clear boundaries.
Which CRM records should each team see? Should they only view customer context, or should they also be able to add information, update records, or create new ones?
Custom User Roles are now available in Mria CRM to give admins control over these decisions.
Why CRM Access in Jira Extends Beyond Sales
When several Jira teams work with the same customer, access is no longer a single choice between full access and read-only access. A role needs to reflect how each team participates in the customer workflow.
Consider two support teams. One may only need to identify the customer behind a request, view the Contact and Company, review previous interactions, and check whether a relevant Deal or Product is involved. For that team, View access may be sufficient.
Another support team may also identify new sales opportunities. Its agents may need to create a Lead, Contact, or Company while handling a Jira Service Management request, add information to an existing record, and pass the resulting context to sales. That workflow requires Create or Edit access.
The same distinction applies to development. A developer evaluating the implementation required for an open Deal may need to review the Deal, its Products, Files, linked Jira or Confluence work, and the information collected during negotiations. If the developer provides the assessment elsewhere, View access may be enough. If the developer is expected to record an estimate in the Deal, add a technical Note, or connect additional Jira work, the role also needs Edit access.
Access also does not have to be identical for everyone within the same team. A custom role can be assigned to an individual user as well as to a Jira group. If only one developer is responsible for estimating Deal implementation, that person can receive a role with the required Deal access while the rest of the development team remains in a more limited role. Similarly, Reports access can be assigned to a finance lead without giving the same visibility to the entire finance team.
For every team, an admin therefore needs to make three separate decisions:
- What customer context should the team see? This may include Leads, Deals, Contacts, Companies, Products, activities, emails, files, and linked work.
- How should the team contribute? Members may only review existing information, or they may also create records, update fields, add context, and support handoffs between teams.
- Which broader capabilities should the team have? Deleting records, changing CRM settings, managing pipelines, accessing reports, viewing all mailboxes, and managing users or roles require separate consideration.
A single predefined User or Viewer role cannot represent all these workflows. The appropriate permissions depend on both the information a team needs and the actions it performs as part of customer-related work.
How Custom User Roles Work in Mria CRM
Mria CRM previously provided three roles with predefined permissions: Admin, User, and Viewer. The Admin role remains fixed and cannot be edited.
Admins can now change the permissions of the existing User and Viewer roles or create additional roles for specific teams and individual responsibilities.
Each role includes a name, a description, and three configuration tabs:
Configure Access by CRM Area and Action
The Roles & Permissions tab defines which parts of Mria CRM the role can access and what users with that role can do there.
Where applicable, permissions are divided into four actions:
They can be configured separately for:
- Leads, Deals, Products, Contacts, and Companies
- Pipelines and stages
- Users and roles
- Emails and email templates
- General and entity settings
- Reports and All Mailboxes
This makes it possible to create different combinations of access. A role can view Deals without editing or deleting them, create Leads without managing pipelines, or work with Contacts and Companies without receiving access to CRM settings.
Some permissions depend on others. When an action requires additional access, Mria CRM applies and locks the required permission automatically.
Enable or Disable Reports Access
Each role has a separate Reports toggle. It enables or disables Reports access for all users and Jira groups assigned to that role.
When Reports is enabled, report data is not filtered by the role’s entity permissions. Users can see Deal, Contact, and Company names and email addresses throughout reports and export this data, regardless of their permissions for those entities.
Assign the Role to Users or Jira Groups
The Users tab assigns the role to individual people. This is useful when a specific person needs access that differs from the rest of their team.
The Groups tab assigns the role to a Jira group. This allows CRM access to follow the team structure already maintained in Jira and makes permissions easier to manage as group membership changes.
The same permissions model can therefore support organization-wide team roles as well as access created for a specific responsibility.
How to Define Mria CRM Access for Teams Working With Customers in Jira
Before opening Roles & Permissions, map the work that each team or individual performs with customer data. Job titles alone are not enough. Two support teams or two developers may require very different access.
1. Map the Customer Handoffs
Start with the recurring workflows where customer context moves between teams.
For each workflow, identify:
- which team receives the work
- which CRM records it needs to review
- what information it contributes
- whether it creates or updates records
- which team receives the next handoff
For example, a support agent may identify a sales opportunity in a Jira Service Management request, create a Lead and Contact, add the relevant context, and hand the opportunity to sales. A developer may later review the resulting Deal to estimate implementation and add the estimate to the record.
These are different responsibilities and should not automatically receive the same role.
2. Decide What Users Need to Do With Each CRM Area
For every relevant CRM area, decide whether the role requires View, Create, Edit, or Delete access.
- Grant View when users only need CRM context to complete work elsewhere.
- Grant Create when the team is responsible for introducing new records into the CRM.
- Grant Edit when users maintain the record or add the results of their work.
- Grant Delete only when removing CRM data is part of the person’s responsibility.
A support team may need View access to Deals and Create access to Leads. A developer reviewing an implementation request may only need View access to Deals. If that developer must record the estimate in the Deal, Edit access is also required.
Permissions apply to a CRM area, rather than to an individual field. Granting Edit access to Deals allows the role to edit Deal data, not only the field that prompted the request. This should be considered when deciding whether information should be added directly by that team or passed to the record owner.
3. Keep CRM Configuration Access With Process Owners
Working with CRM records does not automatically require access to CRM configuration.
Permissions for pipelines and stages, users and roles, general settings, and entity settings should be granted according to who owns the corresponding process.
For example, sales representatives may create and edit Deals without being able to change the pipeline structure. A sales or revenue operations role may manage pipelines and entity settings without receiving the fixed Admin role.
4. Decide on Reports Access Separately
Reports uses a separate on/off toggle and is not limited by the entity permissions configured for the role.
Enable it only when the role requires access to the customer and commercial data shown across reports and needs to export that data. A finance lead or sales manager may require Reports access, while other members of the same team may not.
5. Choose Between Jira Groups and Individual Users
Use Jira groups for permissions that apply consistently to an established team. This keeps CRM access aligned with the team structure already maintained in Jira.
Assign a role to an individual user when the responsibility is specific to that person. For example, one developer may participate in Deal estimates while the rest of the development team does not need Deal access.
Avoid granting broader permissions to an entire Jira group to accommodate a single person. Create a separate role and assign it directly to that user instead.
6. Document and Test Each Role
Use the role name and description to document its purpose. A name such as Deal Implementation Reviewer or Support CRM Contributor is more useful than a generic name such as Custom User.
Before assigning a role broadly, test it with a representative user. Verify both sides:
- the user can complete the expected workflow
- restricted records, settings, reports, and actions remain unavailable
Review the role when responsibilities, team structures, or customer workflows change.
A simple role definition should answer five questions:
- Who receives this role?
- Which CRM areas do they need to see?
- Which records can they create or edit?
- Which actions must remain restricted?
- Should Reports access be enabled?
Configuring a Custom User Role in Mria CRM
To configure a role:
- Open Mria CRM → Settings → Roles & Permissions.
- Select the User or Viewer role to edit, or create a new role.
- Add a name and description explaining the role’s purpose.
- Configure View, Create, Edit, and Delete permissions for each relevant area.
- Enable or disable Reports access.
- Assign individual users or Jira groups.
- Save the role.
You can create as many custom roles as needed, using any combination of the available permissions.
Shared Customer Context in Jira With Clear Access Boundaries
Custom User Roles are part of a larger direction for Mria CRM. We are building customer relationships as a native part of the Atlassian System of Work, so the same customer context can inform Jira work, Atlassian Search, Rovo, and reporting without leaving the Atlassian environment.
As customer context becomes available across more workflows, permissions become part of the system’s foundation. They determine who can discover customer information, who can contribute to it, and who remains responsible for managing CRM data and configuration.
Our vision is for customer context to follow the work while access follows responsibility. This allows organizations to expand collaboration across Jira while keeping visibility, data ownership, and administrative control intentional.
Custom User Roles are one of the foundations for that model. They are now available to all Mria CRM customers.
➡️ Explore Mria CRM on the Atlassian Marketplace
