This content was auto-generated from Fusion SMB documentation and is pending SME review. Please verify accuracy before using in partner-facing contexts.
JSM ↔ Salesforce Integration
Tuxera's Storage Business Unit runs two systems of record that need to stay in sync. Sales works in Salesforce (SF), the CRM that holds customer-centric data. Support works in Jira Service Management (JSM), the ticketing tool that powers the customer support portal. This lesson explains how the two are wired together, what a Tuxera user can do from Salesforce, and where the integration stops today.
Why the integration exists
Salesforce is the source of truth at Tuxera. Information should flow from Salesforce into other systems, and where it makes sense other systems can write back to Salesforce. Before the integration, granting a prospect or customer access to the JSM support portal was a manual, multi-step job. The goal of the integration is to let a Tuxera user grant that access with the click of a button in Salesforce, see the access status in Salesforce, and have a path to remove access later.
The orchestration between the two systems runs through Workato recipes. Salesforce triggers a recipe; Workato talks to JSM; the result is written back onto the Salesforce record.
The object mapping
The single most important thing to internalise is how the two systems' objects line up. A mismatch here is the root of most confusion when reading records.
| Concept | Salesforce | JSM |
|---|---|---|
| A company | Account | Organization |
| A person (paid customer) | Contact | Customer |
| A person (evaluation prospect) | Lead | Customer |
| A paid deployment | Customer Project | (aligned to a JSM Organization in the FUSS project) |
| An evaluation | Lead | (aligned to a JSM Organization in the FES project) |
A JSM Organization is now created from one of two Salesforce starting points, depending on whether the relationship is paid or pre-sales:
- From a Customer Project — the original design (made in the first
iteration), used for paid customers. The Organization lives in the
FUSS (Fusion Support) JSM project and the Salesforce Contact is added
to it. JSM Organization names follow the pattern
{Customer Project Name – CP#ID}— for example,Testing – CP#000922. - From a Lead — used for evaluations. The Organization lives in the FES (Fusion Evaluation Support) JSM project and the Lead itself is added to it.
In both cases the JSM Organization aligns to the Salesforce object that drove its creation rather than directly to the Account. A single Account can therefore have several Customer Projects (each with its own FUSS Organization) and any number of Leads (each with its own FES Organization).
A single Contact may be related to multiple Customer Projects, and therefore to multiple JSM Organizations.
Granting JSM access from Salesforce
Access is granted from two places in Salesforce, depending on the relationship:
- For paid customers, access is granted from the Customer Project record. The JSM Organization lives in the FUSS (Fusion Support) project and the Contact is added to it.
- For evaluations, access is granted from the Lead record. The JSM Organization lives in the FES (Fusion Evaluation Support) project and the Lead is added to it.
In both flows the action creates a JSM Access record in Salesforce that tracks the request through to completion, and Workato does the work in JSM in the background.
The button on the Salesforce record reflects the current state:
| State | Button / status shows |
|---|---|
| No Organization created yet | Add to JSM |
| Organization created, no customers validated | Organization in JSM |
| Organization created and at least one customer validated | JSM Access |
The JSM Access record moves through statuses as Workato works: Requested → Has Access, or Error if something fails.
Access can be viewed from both the Account page and the Contact page. It can be granted from a Customer Project (paid → FUSS) or from a Lead (evaluation → FES); both paths produce a JSM Access record.
The exact Salesforce Record Type IDs and the precise on-screen confirmation wording have changed across iterations and are intentionally left out of this lesson. Confirm the current UI against a live Customer Project before training new starters on the click path.
Adding to multiple projects at once
A single Add to JSM action lets the user select multiple projects. The Workato flow then creates organizations as needed and adds the user to each:
| Scenario | Workato behaviour |
|---|---|
| One project, org already exists | Add the user to the existing org |
| One project, org missing | Create the org, then add the user |
| Multiple projects, all orgs exist | Add the user to each org (no creation) |
| Multiple projects, no orgs exist | Create each org, then add the user |
| Multiple projects, mixed | Per project: create the org only if missing, then add the user |
Domain whitelisting
JSM access depends on the customer's email domain being whitelisted. The whitelist is maintained in Workato, and the relevant recipe checks it whenever access is requested.
- If the domain is already whitelisted, the whitelist step is skipped and the org/customer is created right away.
- If the domain is not yet whitelisted, a task is raised to add the domain to the JSM whitelist before access can proceed.
Deriving the domain from the customer's email address (rather than a separate manual field) keeps the process to a single flow.
The whitelist task is currently routed to a specific person rather than a shared queue. Confirm the current owner / routing so new starters know who actions these.
Evaluation delivery
Sales can send a software evaluation to a prospect with one click from Salesforce, starting from the Lead record. The action:
- sends the evaluation email to the Lead automatically, with the Lead owner copied, and
- provisions a JSM Organization in the FES (Fusion Evaluation Support) project and adds the Lead to it, so JSM access and the evaluation are set up together.
Customer Projects are no longer used to deliver evaluations — that flow is now Lead-driven and lands in FES. Customer-Project-driven access remains the path for paid customers and lands in FUSS.
Behind this sits an Evaluation List custom object that the Enterprise BU uses to drive deliveries.
The evaluation flow has gone through an interim (support-assisted) stage and a fully automated stage. Confirm with the current owner whether the email now always goes straight to the customer/Lead, or whether any deliveries still pass through a manual support step before training on it.
Products covered today
The integration's product catalogue is currently effectively a single product:
- Fusion SMB Server (current)
Two more are coming and will need to be added:
- ESC (Embedded SMB Client)
- Fusion NFS Server
What the integration does not do yet
Set expectations clearly — these are known gaps, not bugs:
- Revoking JSM access from Salesforce is not implemented. Removal is handled manually for now.
- Disabling the "Add to JSM" button once an Organization is already enabled is not implemented.
- A customer-facing request form for JSM access does not exist yet; new contacts are added by the support team.
- A Target Product junction object (which would let a delivery reference any of several products) is future scope, needed once ESC and Fusion NFS Server join the catalogue.
There is a known data-model cleanup outstanding: the Target Record Type used by the Enterprise BU is labelled "Storage" in Salesforce and should read "Enterprise". Until that is corrected, reporting and record-type logic may reference the wrong business unit. Check whether this has been fixed before relying on BU-filtered reports.