01What this guide helps you do
Recognise an application-domain configuration issue.
This guide focuses on one task within troubleshooting & support. Its completion test is specific: The issue is routed to the application configuration owner. Use that result to decide whether the task is finished. Opening a page, entering a value or seeing a brief notification can be part of the process without establishing the complete result.
02When to use this workflow
Use this workflow when your immediate goal is to investigate a JavaScript SDK host error. Keep the scope limited to the relevant support investigation. If you are solving a different problem, use the related guides at the end rather than applying every action here to unrelated records.
The usual operational owner is the person reproducing the issue or the workspace administrator. If another person owns the relevant business facts or permissions, involve that person before changing the shared record. Individual access and business authority are not always the same thing.
03Prepare the information you need
Write the smallest sequence that reproduces the problem. Record the edition, feature, approximate time, expected result and actual result. Use a representative record rather than a whole database. Keep any reference that identifies the event, but omit credentials and unrelated customer information. A precise symptom makes it possible to separate an interface problem from a data, access or provider issue.
Visible host error, application address, support reference.
04Find the right workspace and feature
Start from The affected feature and Support → New support query. Treat this as a feature locator: the arrangement of menus can differ between the web interface and the native application. Confirm the workspace name and the relevant record before proceeding, especially if you manage more than one business or use both India and UK accounts.
The target of this task is a support investigation. Keep its identity visible while you work. A similarly named record or a previously open browser tab can otherwise make a correct action affect the wrong context.
05Understand the information on screen
| Information | What it means | Practical check |
|---|---|---|
| Reproduction | Smallest sequence showing the issue | Use a controlled example |
| Expected result | What should have happened | State the basis clearly |
| Actual result | Observed state and exact error | Do not infer missing evidence |
| Reference and time | Safe locator for investigation | Exclude secrets and unrelated data |
Apply these distinctions to the specific inputs for this guide: visible host error, application address, support reference. You do not need to collect every possible field in the workspace. Use the information needed to make this decision and to verify its result.
06Inspect the current state first
Verify the account context and current saved state first. Then separate validation, network access, workspace permissions, provider status and display freshness. A success notification proves an operation reported completion, not that the user selected the intended value. A timeout can leave the result uncertain, so inspect the record before assuming that the server rejected or cancelled the action.
If the intended result is already present, check whether any further action is necessary. This is particularly useful after an interrupted session or when another teammate may have completed part of the work.
07Step 1: Record the exact error
Begin with the relevant inputs: visible host error, application address, support reference. Resolve any ambiguity that would change which record or business decision the task concerns. Keep a short note of the original state if you will need to compare it later. This creates a clear starting point for the next action instead of relying on memory after several screens have changed.
08Step 2: Confirm the site address used
Use the result of the first action as the context for this one. Check the exact label, selected value or evidence involved rather than assuming that a default matches the intended task. If you identify an inconsistency, resolve it before proceeding. Keep the change narrow enough that its effect can be understood without comparing many unrelated edits.
09Step 3: Contact the platform team for the domain configuration review
Finish by checking the observable result, not only whether the interface accepted an interaction. If the result is still pending or cannot be verified, preserve that distinction in your notes. A clearly recorded unresolved state is more useful than announcing completion and discovering the missing part during a live customer task. Use the verification guidance below for the relevant feature.
10Route this error to the application configuration owner
An unknown-host-domain message concerns the origin from which the application's Facebook JavaScript SDK is running. It is different from a customer lacking access to a Meta business portfolio. A customer should not be asked to create a separate developer application merely to connect through Alactic's hosted signup journey.
Report the exact application address and error wording. The platform administrator can compare the hosted origin with the relevant Meta application's allowed JavaScript SDK domains and login configuration. After the configuration is corrected, retry the normal customer flow. Keep existing legitimate origins when reviewing that shared configuration so another product journey is not accidentally broken.
| Check | Meaning for this task |
|---|---|
| Useful customer evidence | Hosted page address and exact error |
| Responsible configuration | The platform's Meta login application |
| Retest | Normal signup from the affected hosted origin |
11Worked example
A UK user reports the host error with the application URL rather than changing business ownership settings.
The useful lesson is the sequence of decisions, not a promised result for every business. In this scenario, begin with “Record the exact error”, continue with “Confirm the site address used”, and finish with “Contact the platform team for the domain configuration review”. Compare the result with the completion test before applying the same process to a wider set of records.
Use invented names and references when practising this example. Keep the structure realistic, but do not copy a live customer conversation or payment record into training material simply to make the demonstration look authentic.
12Verify the result
Change one relevant factor and repeat the original small example. Compare the actual result with the expectation recorded before the change. If comparing devices or reports, align the workspace, record and filters. A successful unrelated test does not resolve the reported issue. Keep a short record of what changed so support or another operator can understand why the correction worked.
The issue is routed to the application configuration owner.
13Decide what to do next
| What you observe | Appropriate next step | What to avoid |
|---|---|---|
| The expected result is visibly present. | Keep the result and continue with the intended business task. | Repeating a completed action without a reason. |
| The result is still pending or uncertain. | Review the current support investigation and the relevant status. | Calling the task complete without evidence. |
| The result conflicts with the intended choice. | Revisit: Confirm the site address used. | Changing unrelated records to hide the symptom. |
Use the observed state to choose a branch. A recovery action should address the actual cause and preserve any work that is already correct. If several people are involved, make the next owner explicit so a pending state does not become an unattended task.
14The main mistake to avoid
A customer should not have to add the platform's domain to their own unrelated Meta app.
This mistake can make the task appear finished while leaving the business outcome unresolved. Return to the inputs and the named steps when the result is unclear. Keep a useful distinction between what you observed and what you expected. If a weaker signal is all that is available, describe the remaining uncertainty and identify how it can be checked.
15Diagnose an unexpected result
Compare the expected result with the exact current state of the support investigation. Record which of the three actions was last completed and what happened next. Keep the exact validation message or visible status where one exists. This separates an input problem from a saved-state problem and helps another person reproduce the same example.
Check the workspace, selected record and current view. Change one relevant factor at a time. If you change several unrelated settings together, a later success may not explain which change actually resolved the issue.
16Recover without duplicating work
Prefer a narrow correction based on the observed cause. Avoid repeated bulk imports, sends or payments while the original outcome is uncertain. For provider decisions, use the relevant status and official route instead of bypassing local checks. For persistent product discrepancies, include one reproducible reference and the exact error. Preserve original records so investigation does not lose the evidence it needs.
If the result depends on a provider or another authorised person, record that dependency and use the appropriate route. Do not simulate success by manually changing an unrelated display value or by removing evidence of the original outcome.
17Use the workflow on web and mobile
For mobile issues, include the installed app version, device context and text-size settings when relevant. Close the keyboard and review the full form before concluding a field is absent. Compare notification delivery separately from the underlying inbox event. A redacted screenshot should show the affected control and screen name without revealing unrelated customer conversations or financial information.
When comparing devices, match the same account, record and relevant filters. A desktop screenshot and a mobile screen from different contexts are not evidence of inconsistent data. If a layout problem prevents completing the task, report the screen name, device context and the affected control with private details removed.
18Keep a useful operational record
Retain only the information needed to explain the task: its purpose, the relevant support investigation, the action taken and the observed result. If the operation produced a safe reference, keep it with the time and workspace context. This makes a later handover or support query more precise than a screenshot with no explanation.
| Record | Useful content |
|---|---|
| Purpose | Recognise an application-domain configuration issue. |
| Inputs reviewed | Visible host error, application address, support reference |
| Outcome to verify | The issue is routed to the application configuration owner. |
| Next owner | Person reproducing the issue or the workspace administrator |
19Protect private information
Use the minimum customer or business information needed for the task. Restrict access to authorised colleagues, and redact unrelated names, numbers and message content when sharing a screenshot. An evidence reference is often more suitable than copying the underlying private document into a general field or support message.
For this workflow, the useful input categories are visible host error, application address, support reference. They should help you make and verify the decision; they are not a reason to publish a customer database, credentials or internal operating notes. The fictional example in this guide can be used for training without exposing live records.
20Know the limits of this workflow
When a write times out, the result may be uncertain. Inspect the current saved state before repeating an action that could send, publish, import or charge.
Capture the exact symptom, isolate the affected scope, test one change and record the result. Useful evidence explains the problem without sharing secrets or unrelated customer data.
Read the linked source material for decisions controlled by a provider or by the applicable commercial terms. A practical guide explains how to approach the task; it does not add a new contractual guarantee or establish that every business use is legally suitable. Use the responsible business owner for unresolved exceptions.
21Review the process over time
Turn recurring problems into small regression examples and clear operating guidance. Record the resolution in terms of the actual cause, not merely that the page was refreshed. Review whether an error message can be made more actionable. An effective troubleshooting routine reduces repeated uncertainty while avoiding destructive resets or manual record changes that conceal a broken core workflow.
Update related instructions when the underlying business fact or product behaviour changes. Keep a representative example from this workflow so a future revision can be compared with an explicit expectation rather than judged from memory.
22Practical questions
What should I check before starting?
Prepare visible host error, application address, support reference. Then confirm the workspace and the relevant support investigation. The first action is “Record the exact error”. Starting there keeps later decisions grounded in the correct record and avoids trying to solve a different problem with this workflow.
How do I know the task is complete?
Use this observable test: The issue is routed to the application configuration owner. If a state is pending, describe it as pending. If a save or provider operation is uncertain, inspect the current record before repeating it. The result matters more than whether a button was pressed.
What if the result still does not match?
Review this risk first: A customer should not have to add the platform's domain to their own unrelated Meta app. Keep the exact symptom, the relevant reference and the last completed action. Ask the person reproducing the issue or the workspace administrator or the appropriate support route to review the remaining issue, using a small reproducible example rather than a broad export of customer data.
23Completion checklist
Use this checklist as a final review of the task, not as a substitute for the steps above. If an item remains unresolved, identify the next action and its owner. Do not mark a provider-dependent or unverified result complete merely because the rest of the checklist is finished.
- The intended workspace and support investigation were identified.
- The necessary inputs were reviewed: visible host error, application address, support reference.
- Record the exact error.
- Confirm the site address used.
- Contact the platform team for the domain configuration review.
- The result was checked: The issue is routed to the application configuration owner.
- The task-specific risk was considered: A customer should not have to add the platform's domain to their own unrelated Meta app.
- Any unresolved issue has an accountable next owner and a useful evidence reference.