Contact us

A useful problem report begins with the page you were using and the question you wanted the result to answer. Say whether you were cleaning text, appending records, matching keys, comparing versions, or preparing a file for another application. Include the interface language, because a label may be clearer in one language than another. Describe the expected output in concrete terms: six records instead of eight, one field added by a key, or a particular value preserved as text.

Then describe what actually happened. An error message, an unexpected count, and a surprising value are different clues. Copy the wording of an error if possible, and note the step at which it appeared. Avoid replacing the detail with a general description such as “the file is wrong.” A short explanation of the difference between the expected and actual result is usually more helpful than a large screenshot with no indication of which row matters.

If an email address is displayed on this page, that is the configured route for questions and feedback. Opening its email link uses your own mail application. Review the recipient, message, and attachments before sending. The workbench does not send feedback automatically when a tool reports an error. If no address has been configured, this page explains that state; it does not pretend that a message has been submitted or provide a form that silently discards your report.

There is no published response-time commitment on this page. Keep your own notes and source files while investigating an issue. If the work is urgent, use the guides to check the parsing and operation choices and keep any result you can safely review. Reporting a problem does not recover an ended session, complete an external import, or change the files already downloaded to your device.

A few invented records can reproduce many table issues. Keep the relevant structure: the same number of important columns, the same separator, a duplicate key if duplicates matter, and a blank field if blank handling is involved. Replace names, addresses, account numbers, transaction references, and other sensitive values. Preserve the shape of a problematic identifier, such as five characters with leading zeros, while changing its actual value. Include only the columns needed to demonstrate the behaviour.

Make sure the reduced example still produces the problem. If it does not, note what changed between the original and the reduced input. Quoted commas, embedded newlines, unusual whitespace, and field order can be important. For a workbook, a selected range, hidden row, or formula with an unavailable cached value may be relevant. A synthetic example should preserve that condition rather than remove it and unintentionally describe a different issue.

Parsing choices determine how the tool reads a file before it performs the requested operation. Note the encoding when it is selected, the delimiter, whether the first record contains headers, and whether any initial rows are skipped. Explain whether the source was uploaded, pasted, taken from the current table, or selected from a worksheet. The same visible text can behave differently if one import used a different header or range.

For operation rules, record the selected fields and the choices that determine meaning. A comparison needs its matching keys and compared columns. A merge needs its column strategy and mappings. A date conversion needs its source pattern and time zone where applicable. A number conversion needs its decimal and grouping conventions. If a saved rule file is relevant, inspect it before sharing: it can contain column names, replacement strings, or constants even when it contains no full table.

If the issue concerns missing or extra records, include the input count, result count, and the count of any exception or excluded-record report. Say whether you are looking at a full result or just the current grid page. Search within a grid is a viewing aid; it is not necessarily a filter on the dataset that will be exported. Note the download scope you selected and whether you expected all records, only changes, or a supporting report.

For a join, describe whether a key appears once or several times in each input. For expanded list cells, note how many items belong to one source record. For a grouped result, identify the fields defining a group. These details often explain a count difference without requiring the complete source. A known record whose journey you can follow from input to output is particularly useful when the total alone does not reveal the cause.

Include your browser name and version, device type, and whether the problem occurs consistently. It helps to know whether the issue happens while selecting a file, parsing, running a task, reviewing a result, or downloading. If the page remains usable but a button is unavailable, record the nearby message and whether a required confirmation is still pending. If a layout is difficult to use, include the approximate window size and whether you have enlarged the text.

A browser session is held in memory. Do not refresh simply to obtain a cleaner screenshot before exporting work you need. If a refresh is part of your reproduction, start from a synthetic example or a saved input and describe it explicitly. Some specialised workspaces have separate state from the shared table workflow. Include the sequence of pages you visited if the problem concerns switching tools or changing the interface language.

For calendar, contact, and product imports, explain whether the problem occurred here or in the receiving application. A successful download means a file was generated; it does not mean the destination accepted it. Include the destination’s exact error message and the kind of import you attempted. State whether you were adding new items or updating existing ones, because duplicate and overwrite behaviour can differ. Remove account identifiers and private information from any shared message.

Try a small fictional batch that you can identify and remove in the destination if your normal workflow allows it. Check time zones for events, name and phone mappings for contacts, and the selected template or schema for product files. Do not repeatedly import the complete source while guessing at the cause. Keep a copy of the generated file and note the export options so that the difference between generation and destination behaviour remains clear.

For a feature request, describe the task you cannot currently complete, the input you have, and the output you need. Explain where the existing tools stop short. A request to “support more formats” becomes easier to assess when it names the format, the relevant data features, and a fictional example. A request for a new matching rule is clearer when it explains what should happen to duplicate keys, empty values, and unmatched records.

For wording feedback, include the current label and what you understood it to mean. English and Simplified Chinese help should sound natural while describing the same underlying behaviour. If a FAQ answer appears to promise a result the tool does not offer, identify the question and the step you tried. Clear feedback about a specific mismatch is more actionable than a general request to simplify the entire interface.