Custom Service Escalation

Custom Service Escalation

Escalate a requirement when the intended result cannot be produced safely through the supported migration path, standard configuration, purchased Add-ons, or already approved Customization. A precise escalation allows Next-Cart to distinguish a supported-feature defect from new or changed Custom Service work and assess the correct next action.

Use this page after the relevant setup, configuration, migration, or validation checks have identified a non-standard requirement or an approved tailored result that requires Next-Cart intervention.

Not every support issue is Custom Service

A supported feature that fails to behave as documented is a support issue. Custom Service applies when the required extraction, transformation, mapping, relationship, destination, or platform behavior is outside the supported standard scope or changes the approved tailored scope.

Choose the correct escalation path

Situation	Correct path
A supported connection, option, mapping, Add-on, migration action, or validation result does not behave as documented	Submit a support ticket with reproducible evidence. Do not redefine the problem as Custom Service.
A purchased Add-on or approved Customization item is missing, inactive, or produces an unexpected result	Diagnose through Add-on and Customization Issues, then escalate with the approved scope reference if Next-Cart intervention is required.
The required source data remains outside supported data selection, Advanced Data Mapping, or eligible Advanced Database Mapping scope, including unsupported tables, files, apps, plugins, modules, or external systems	Prepare the unsupported portion as a Custom Service requirement.
The target needs a field, relationship, storage location, or behavior that remains outside supported mapping and target-platform handling	Prepare a Custom Service requirement and confirm target readiness or an approved fallback.
The required logic is conditional, multi-field, multi-stage, relationship-dependent, or not representable through purchased Add-ons	Prepare a testable Custom Service rule.
An approved requirement changed after assessment or implementation	Submit the changed requirement as a scope review. Do not assume the existing Customization covers it.
The issue belongs to the source platform, target platform, hosting provider, or third-party application	Preserve the migration evidence and request the platform-specific correction from the responsible platform or provider; use Custom Service only when Next-Cart must implement non-standard migration handling.

Confirm the escalation threshold

Before requesting Custom Service, verify that the requirement is not already covered by:

• supported data-type selection;
• Additional Options;
• Attribute Mapping;
• Data Filter;
• Data Transformation;
• Advanced Data Mapping;
• Advanced Database Mapping when both platforms are Open-Source;
• an existing approved Customization item;
• a target-store setting, field, application, or platform behavior outside migration processing.

When one of these supported paths covers the requirement, correct or troubleshoot that path first. Do not use Custom Service as a substitute for incomplete setup, an incorrect configuration, a target-store display issue, or missing validation evidence.

Prepare an escalation that can be assessed

1. State the customer outcome

   Describe what the target-store user, administrator, integration, or business process must be able to do after migration.

2. Identify the affected scope

   Name the data type, migration path, stores, languages, sites, customer groups, date range, or other boundary involved.

3. Identify the source location

   Provide the exact field, table, export column, metafield, app, plugin, module, API property, file, or external-system location. Include representative identifiers.

4. Define the target result

   State the intended target field, custom field, relationship, note, tag, table, reference, or operational behavior. Confirm whether that destination already exists.

5. Write testable rules

   Use if/then logic where possible. Define empty values, invalid values, fallbacks, precedence, conflicts, and relationship behavior.

6. Provide representative examples

   Include normal examples and edge cases. Use stable identifiers and show the source value, expected target result, and actual result when an implementation already exists.

7. List dependencies and constraints

   Identify required access, exports, applications, custom fields, target settings, related data types, timing, ordering, or third-party coordination.

8. Define pass conditions

   State what must match, which differences are acceptable, what would block acceptance, and how the result will be sampled and verified.

9. Separate related requirements from unrelated issues

   Keep one requirement group in one ticket thread. Create separate tickets for unrelated behaviors so scope, decisions, and evidence remain traceable.

Evidence checklist

Evidence	What to provide
Service context	Order # or migration reference, fixed migration path, and affected activity or History entry.
Requirement name	A short, unique description of one outcome.
Affected data	Data type, representative source records, stable identifiers, and relevant relationships.
Source location	Exact field, table, export, app, plugin, module, API property, file, or external-system location.
Target destination	Exact native field, custom field, relationship, storage location, or behavior.
Rule	Conditions, source values, expected target values, fallbacks, and precedence.
Examples	Normal records, empty values, unusual values, duplicates, and other edge cases.
Current evidence	Screenshots, masked extracts, logs, Failed or Skipped results, and expected-versus-actual comparisons.
Dependencies	Access, target preparation, other data types, mappings, Add-ons, Customization, or third-party systems.
Acceptance criteria	Sample coverage, pass conditions, accepted limitations, and blockers.
Business impact	Launch blocker, operational consequence, affected volume, and required decision date where relevant.

Share only the evidence needed for assessment

Mask personal data and secrets. Do not send passwords, complete secret keys, payment-card data, unrestricted database dumps, or unrelated customer records. Use the secure transfer path requested by Next-Cart when larger or sensitive evidence is required.

Distinguish a new requirement from an implementation issue

Question	New or changed Custom Service requirement	Existing implementation issue
Was the behavior previously approved?	No, or the requirement changed.	Yes.
Does the expected result match the approved examples and pass conditions?	Not yet defined or materially different.	Yes.
Is the required source location and target destination already in scope?	No or uncertain.	Yes.
Is the required item available and selected where applicable?	May not exist yet.	It should exist and be active.
Primary next action	Requirement assessment and scope confirmation.	Reproduce the mismatch and investigate the approved implementation.

Verification before submission

The escalation is ready when:

• one customer outcome and one affected scope are clear;
• standard configuration and purchased Add-ons have been ruled out with evidence;
• the source location and target destination are specific;
• the rule is testable and includes fallback behavior;
• normal examples and edge cases are included;
• dependencies and target preparation are identified;
• pass conditions and blockers are measurable;
• sensitive data is minimized or masked;
• the request can be tracked in one focused ticket thread.

Submit and track the escalation

Use Tickets to submit the requirement or implementation issue. Include the approved requirement reference when applicable, keep requested follow-up evidence in the same thread, and verify the result against the documented examples before closing the ticket.

For a new or changed requirement that still needs full definition, use Prepare Custom Service Requirements before submission.