Skip to main content

Tag: Service Delivery

Nexum Workflow Update: More Control Over Ticket Progress, Approval and Escalation

Written by admin on . Posted in News.

Service work rarely follows one simple path. A small support request can become an equipment quote, a customer approval, an implementation task, a stock reservation, or a billing decision. When that happens, teams need the PSA to guide the work without forcing every ticket into the same fixed process.

The latest Nexum Workflow update expands how Nexum PSA controls ticket progress. Instead of treating workflow as a basic status list, Nexum can now describe the steps, requirements, allowed actions, approvals and escalation paths that belong to the actual work being handled.

From status changes to controlled service workflow

A ticket status is useful for reporting, but it is not always detailed enough for daily operations. Two different steps can both be reported as In progress while still needing different rules. One step may allow diagnosis and internal notes. Another may require customer approval before equipment can be reserved or work can continue.

Nexum Workflow now separates operational workflow states from broader reporting statuses. This gives administrators more control over the real service delivery process while keeping normal reporting understandable.

Clear requirements before the next action

Workflow requirements can now be built as readable groups. A workflow can require all conditions in a group, or at least one condition from a group.

For example, a ticket may be allowed to move forward when the customer has approved the work in writing, uploaded a signature, or already has a valid contract, while also requiring that the correct asset is linked to the ticket.

This matters because many MSP and IT provider workflows are conditional. A technician should not have to remember every exception manually. Nexum can show what is missing and why the next step is blocked.

Actions can be available, hidden, blocked or conditional

Each workflow state can control what technicians are allowed to do. Actions such as replying to the customer, adding internal notes, assigning the ticket, registering time, planning costs, creating a quote, reserving equipment, requesting review, escalating, or closing the ticket can be handled differently in each state.

An action can be available, hidden, blocked with an explanation, or conditional based on requirements. The same decision is enforced on the server for both the browser and the API. In practical terms, the button is not the security control. The workflow decision is.

Escalation when the work changes shape

Some tickets start as support and later become something else. A diagnostic ticket may reveal that the customer needs new equipment. A normal support request may become a sales quote, an implementation job, or work that needs a senior technician.

Nexum Workflow can now define internal escalation paths from one workflow to another. Escalation is still a deliberate technician action. It is not the same as Nexum-to-Nexum provider escalation, and it does not silently move work behind the scenes.

Administrators can decide whether an escalation is optional or required. If required, protected actions such as closing the ticket or adding actual costs can stay blocked until the ticket has been moved into the right workflow, queue, type or eligible owner pool.

Approval, review and customer evidence

The update also adds stronger support for approval-driven work. A workflow can require a senior review before a protected action is allowed. It can also rely on specific customer evidence, such as a classified customer response or uploaded signature, instead of treating any old message or attachment as approval.

Senior review is designed as a traceable checkpoint. If important evidence changes after approval, the previous review can be invalidated and a new review can be required. This gives teams a more controlled four-eyes process without turning every ticket into a separate project.

Quotes, planned scope and approved fulfilment

For commercial work, planned scope is now separated from actual cost. A technician can plan equipment, time or service lines before anything is reserved, ordered, billed or counted as delivered.

When approval is needed, Nexum can use the Sales quote engine from the ticket context. A quote can be created from planned ticket lines, sent with an immutable PDF snapshot and accepted through a secure link, the customer portal, or recorded email acceptance when handled by an authorized technician.

After approval, the accepted scope can unlock the correct implementation work. Approved equipment lines can be converted into storage reservations or draft purchase needs, while completed work can continue toward the existing business operations and economy process. Vendor orders and billing are still explicit controlled actions, not automatic side effects.

Versioned workflow publishing

Workflow changes are also safer for active tickets. Saving the editor creates a draft. Publishing creates a numbered workflow version. New tickets use the published version they start with, so later edits do not silently change the rules for active work.

When an administrator wants to move existing active tickets to a newer workflow version, Nexum supports an explicit migration preview. That preview shows how states map before anything is applied.

Why this matters for MSPs and IT providers

For MSPs and IT providers, the value is operational control. Nexum Workflow helps teams make the right action obvious, block risky shortcuts, keep approvals attached to the right ticket, and connect support, sales, storage and billing without losing the audit trail.

For managers, it means the process can match the type of work instead of relying on memory, side notes or manual follow-up. For technicians, it means fewer unclear next steps and better explanations when a ticket cannot move forward yet.

The update also strengthens Nexum’s automation and API story. API clients can inspect workflow decisions and perform workflow-approved operations through the same guardrails as the technician interface.

Built around control and auditability

Workflow does not grant permissions a user does not already have. It can narrow what is allowed, require evidence, ask for senior review, or block an action until another step is complete. Ordinary permissions, domain rules and workflow rules work together.

Every important workflow event can be recorded in ticket history: transitions, escalation, review, evidence classification, quote acceptance, purchase need, migration and close outcome. That is important for internal quality, customer communication and later billing review.

This update is part of the current Nexum PSA beta work. It is especially relevant for teams that need a PSA workflow that can handle support, approvals, quotes, implementation and operational control in one connected process.

To learn more about the surrounding platform, see Service Delivery, Security & Control, Automation & Integrations, or the available Nexum PSA plans.

Nexum Collaboration: Secure Ticket Escalation Between Independent PSA Portals

Written by admin on . Posted in News.

Collaboration across company boundaries is often harder than it should be. A customer reports an issue in one portal, the IT provider works it in another, and the handover quickly becomes a mix of forwarded emails, copied ticket text, missing attachments and unclear status updates.

Nexum Collaboration is designed to make that handover cleaner for MSPs, IT providers and customers who both use Nexum PSA. It gives two independent Nexum installations a controlled way to work together on selected tickets without combining databases or exposing internal operational data.

What Nexum Collaboration does

Nexum PSA collaboration connects two separate Nexum PSA installations through an explicit relationship. One portal can act as the customer-side Nexum, while the other can act as the provider-side Nexum.

When the relationship is configured, the customer-side portal can escalate selected tickets to the provider-side portal. The provider receives the escalated ticket under the correct client, so the work lands in the right operational context instead of arriving as a disconnected email or manual copy.

The goal is simple: keep each organization in control of its own service delivery workflow, while giving both sides a clearer shared channel for the parts of the ticket that should move across the boundary.

Example: a customer escalates an issue to their IT provider

Imagine a customer that runs its own Nexum PSA portal for internal IT requests. One of its users reports an issue that needs help from an external provider. Instead of copying the ticket into email, the customer can escalate that specific ticket through the configured Nexum relationship.

The provider receives the issue inside its own Nexum portal, connected to the right client record. The provider team can triage, assign and work the ticket using its own queues, permissions and processes. Public replies can then sync back to the customer-side ticket, keeping the requester informed without giving either side unnecessary access to the other’s portal.

What can sync between portals

The relationship can sync the customer-facing parts of the ticket workflow that both sides need to collaborate effectively:

  • Selected tickets escalated from the customer-side Nexum to the provider-side Nexum.
  • Public replies, which can sync in both directions.
  • Ticket status updates, using configured status mapping between the two portals.
  • Attachments, when the relationship policy allows attachment sync.

Status mapping is important because two organizations may not use identical ticket stages. One portal might use a status such as Waiting for provider, while the other uses In progress or Waiting for customer. Mapping lets each side keep its own workflow language while still sharing useful progress updates.

This also fits the broader Nexum approach to automation and integrations: sync should reduce repeated work without forcing every organization into the same internal process.

What stays private

Nexum Collaboration is not a shared database, a tenant merge or a shortcut into another company’s PSA. Each Nexum installation keeps its own database, users, permissions, workflows and private data.

By default, internal operational records stay internal. That includes internal notes, time entries, costs, margins, assignments, credentials and internal documentation. The relationship is built around selected sync behavior, not broad portal access.

This distinction matters for MSP collaboration because providers need to coordinate with customers without exposing commercial details, internal work notes or service desk structure. Customers also need visibility into their escalated issue without inheriting the provider’s internal ticket system.

Why this matters for MSPs and customers

For MSPs and IT providers, Nexum Collaboration can reduce duplicate ticket entry and make customer escalations easier to track. The provider can receive work in its own PSA portal, under the right client, with the right workflow controls. The result is a cleaner IT provider workflow for work that crosses company boundaries.

For customers, it creates a clearer escalation path. They can keep using their own PSA portal for intake, visibility and follow-up, while still collaborating with the provider when an issue needs outside help.

For both sides, the value is less manual coordination. Public communication, status movement and allowed attachments can follow the ticket instead of being retyped, forwarded or reconciled after the fact.

Security and auditability

The security model is based on scoped relationships rather than broad system access. Communication uses scoped tokens, signed webhooks and sync links so each portal can identify the relationship, verify incoming updates and connect the correct mirrored records.

Audit logging records sync activity, and health status makes it easier to see whether the relationship is working as expected. This gives administrators a practical way to monitor the connection instead of treating ticket sync as a hidden background process.

Just as important, this is not an SSH-based integration. The collaboration capability is designed as an application-level Nexum-to-Nexum relationship, with explicit configuration and policy controls.

Looking ahead

The same relationship model also creates room for optional advanced use cases, such as selected non-internal documentation and knowledge sharing when those capabilities are explicitly enabled. The principle remains the same: share what is useful for collaboration, keep internal material private unless policy says otherwise.

Nexum Collaboration is now part of the product direction for teams that need secure ticket sync across organizational boundaries. MSPs, IT providers and customers evaluating this workflow can review the security and control, service delivery and support areas of Nexum PSA, or compare the available plans.