A store in this state has stopped working completely: order history does not load in a conversation, abandoned carts stop arriving, and order actions are unavailable. The product is not retrying in the background, because retrying with access the store has refused would not help. Only an administrator can fix it, and it takes one action: Settings → Commerce → the store → Reconnect. What the product is telling you | What you see | The code behind it | |---|---| | “This store needs to be reconnected” in Settings → Commerce | the store's status is needs_reauth | | “We could not reach your store” in a conversation panel | AUTH_INVALID | The status is durable: it was written the moment the store refused the access, and it stays until somebody reconnects. It is not a guess from a single failed request. Why it happens The reason differs per platform, and it is worth knowing because two of them can happen without anybody doing anything wrong. - WooCommerce — the API key was deleted, or its permissions were changed, in WordPress → WooCommerce → Settings → Advanced → REST API. This is the one that is usually deliberate: somebody tidied up keys. - Salla — the app was uninstalled or its authorization lapsed in the Salla dashboard. Reinstalling the app reconnects the store on its own; you do not need to create a new connection code unless the store is also gone from the list. - Zid — the authorization expired, or the app was removed. Zid also sometimes answers a rejected authorization with a redirect to its login page rather than a refusal, and the product treats that as a rejected authorization, which is the correct reading. - Shopify — the app was uninstalled from the store's admin, or the access it was granted was revoked. What is kept and what is removed Reconnecting does not start you from scratch, and disconnecting does not delete your history: - the store's access is removed when it moves to this state, and so is its cached data, which is why panels go blank rather than showing something stale; - conversations, contacts and your order-action history stay. They are Lynomia's own records, not the store's; - a store you disconnect keeps its row, so reconnecting the same store later reuses it rather than counting against your plan's store limit twice. If reconnecting does not hold If the store moves back into this state within minutes of reconnecting, the access you granted is not the access the product needs — it connected and then was refused on its first real request. That is a permissions problem rather than an authorization one: see Your store keys cannot do that.

Troubleshooting

An order action did not apply

An order action — cancelling an order, changing its status, issuing a refund — is the only thing Lynomia writes to your store. Everything about how it behaves follows from one rule: a write is never sent twice. A duplicate refund is worse than a failure you can see. Every outcome, and what to do | What you see | The code | What actually happened | What to do | |---|---|---|---| | “The order changed while you were looking at it” | ORDER_CHANGED | somebody else changed the order between the panel loading and the action being sent | re-open the order and try again on the current state | | “That did not apply” | NOT_APPLIED | the store accepted the request and the order is provably unchanged | safe to try again | | “Your store declined the refund” | REFUND_DECLINED | the payment gateway refused, not the store | refund from the store's own admin, where the gateway's reason is visible | | “Your store refused that” | PROVIDER_REJECTED | the store rejected the action itself | check the order in the store's admin; it is usually in a state that does not allow it | | “That action is already running” | ACTION_IN_PROGRESS | the same action is in flight | wait; do not start a second | | “That amount is not valid” | INVALID_AMOUNT | the amount is outside what the order allows | check the order total and what has already been refunded | | “We do not know whether that applied” | an unknown outcome | the request was sent and the answer was lost | read the rest of this page | | “Order actions are turned off” | ACTIONS_DISABLED | the switch is off for this store | an administrator turns it on in Settings → Commerce | | “That action is not available for this store” | ACTION_UNAVAILABLE | the platform does not support it | nothing; it is a capability, not a fault | “We do not know” is an honest answer, not a bug If the request reached your store and the answer was lost — a timeout after sending, a dropped connection — then Lynomia genuinely cannot tell whether the action applied. It will not guess, and it will not send the action again to find out. What it does instead: 1. It reads the order back, a little later, and judges only by what the store says now. If the order is in the state the action asked for, the action succeeded. If it is provably in the state it started in, the action failed and is safe to retry. 2. If reading back cannot settle it, the action stays recorded as unknown, and the panel says so. 3. It never re-sends. An action that may have applied is not sent again by the product under any circumstances. If an action is sitting at unknown, open the order in your store's admin. That is the authoritative answer, and it takes a few seconds. Why actions are deliberate rather than convenient - they are off per store until an administrator turns them on; - they need credentials that can write — see Your store keys cannot do that; - they are checked against the order as the agent saw it, which is what produces ORDER_CHANGED rather than a surprise; - every one is recorded with who ran it and what the store answered. That is four opportunities for an action to be refused, and each refusal is a sentence rather than a silence.

Administration

The record of your imports

Every import this account has run is listed under Settings → Data, newest first. Each row opens a page that says who started it, how long it took, how many records went in, and — the part worth the trip — which records did not, with a reason for each. This article is about that record. How to run a contact import from a file is import contacts; this is what you read afterwards, and what you read when somebody asks what happened to the twelve rows that never appeared. When to use it - After an import, to see what was skipped rather than assuming nothing was. - During a long import, to see which stage it is on. - When somebody asks who brought a list of contacts into the account, and when. - When an import appears stuck, to retry or abandon it. When not to use it - To get data out. There is an Export tab and it says Coming soon. Nothing is exported from this page today. - As a general audit trail. Imports are the only thing on this page. For settings changes and sign-ins, see audit logs. - To undo an import. Nothing on this page reverses one. An import is a write, and the records it created are ordinary contacts and conversations from then on. What you need first An administrator account, and the data-import capability enabled for your account. On an account without it, Data is simply absent from Settings and the pages behind it refuse access. There is no custom role permission for this, so it cannot be delegated — see roles and permissions. The list | Column | What it tells you | |---|---| | Name | what the import was called when it was started, or Untitled import | | Type | contacts, conversations, or both | | Status | where it is, or how it ended | | Imported | how many records have gone in so far | | Created | when it was started | While an import is running the list updates itself every five seconds, and there is a Refresh button if you would rather not wait. A row opens the import's own page. The stages The status is not a simple pass or fail. It walks through the work: | Status | Meaning | |---|---| | Queued | accepted, not started yet | | Importing contacts | working through the contacts | | Importing conversations | working through the conversations | | Finalizing import | tidying up at the end | | Completed | finished, nothing skipped | | Completed with errors | finished, and some records did not go in | | Failed | could not finish | | Abandoned | you stopped it, or it was stopped | Completed with errors is the status people misread. It means the import finished and records were lost. Open it and read the logs; do not treat it as a success. The import's own page | | | |---|---| | Source | where the records came from | | Import types | contacts, conversations, or both | | Created / Duration | when it started and how long it took | | Started by | the person who ran it. This is the "who did it" | | Import progress | N of M imported, or just N imported when the total is not known in advance | | Errors | a record that could not be created, with a code, the object it came from and a message | | Skip logs | a record that was deliberately not created, with its kind, source object and message | Errors and skip logs are different things and the page keeps them apart. An error is a failure; a skip is a decision — a duplicate, or a record that did not qualify. Both lists download as CSV, which is how you hand them to whoever owns the source data. If both are empty the page says so plainly: No errors recorded and No skipped or failed records recorded. Where imports come from The New import panel offers a file, and the support tools your installation has enabled. Whichever you choose, you pick the data to import — contacts, conversations, or both. Only one import runs at a time. Starting a second while one is active is refused with Wait for the active import to finish before starting another one. This is a queue of one, not a queue. Credentials you paste for a connected source are stored encrypted where your installation has encryption configured, and are never shown back to you. Retry and Abandon Two actions appear on an import that is still active, and they are narrower than they look. Retry resumes an import that has stalled — made no progress for fifteen minutes. It is not a "run it again" button: on an import that is simply slow, it answers This import is no longer stalled and does nothing. It is also refused when another import of the same kind is already in progress, or when the credential the import was started with is no longer available. Abandon stops an active import. What was already imported stays; nothing is rolled back. The row keeps its history and reads Abandoned from then on. Neither action exists on a finished import. A completed, failed or abandoned import is a record, not a job. A worked example An administrator at a Kuwait retailer imports 3,400 contacts and tells the team it is done. A week later somebody notices a customer is missing. They open Settings → Data, find the import, and see Completed with errors. The import's page shows 3,388 imported and twelve in the error list — all twelve with the same message about an unusable phone number. They download the CSV, send it to the person who produced the file, and re-import the corrected twelve rows. Nothing was mysterious; it was written down the whole time. Who can do this Administrators only, for all of it — the list, each import's page, the logs, retry and abandon. An agent cannot see this page at all, and the list is empty rather than partial for anyone else. Limits - Export does nothing yet. The tab exists and says so. - One import at a time. - Retry only works on a stalled import, which means fifteen minutes without progress. - Nothing undoes an import. Abandon stops it; it does not reverse what was already written. - A skipped record is not retried for you. Download the CSV and fix it at the source. - The page shows imports only. It is not a general record of changes — that is audit logs. - Starting an import is not itself in the audit log, so this page is the only record that it happened. - There is no notification when an import finishes. You come back and look. Related - Import contacts · Bulk actions - Contacts · Custom attributes - Audit logs - Roles and permissions If it does not work Data is not in Settings. The capability is not enabled for your account, or you are not an administrator. Nothing in your account turns it on. The status says Completed with errors and I do not know what is missing. Open the import and read the Errors and Skip logs tables. Download both as CSV. Retry says the import is no longer stalled. It is still working. Stalled means fifteen minutes with no progress; wait and look again. Retry says a credential is unavailable. The key the import was started with is gone. Start a new import rather than retrying this one. I cannot start an import. One is already running. Finish it or abandon it first. The counts stop moving. Give it fifteen minutes, then retry. The list refreshes itself every five seconds, so a frozen count is a real observation and not a stale page.

Administration

Audit logs

The audit log is a read-only record of configuration changes and sign-ins, under Settings → Audit Logs. Each entry says who did what, and when. It is not a record of work. Replying to a customer, resolving a conversation, labelling it or running a macro leave no entry. If you want to know what your team did with a conversation, the conversation itself is the record — see work in the inbox. What is recorded The page groups events in four families, and the filter offers exactly these fourteen: | Group | Events | |---|---| | Access | sign-in and sign-out | | Agents and teams | agents (invited, role changed, availability changed), teams, team members, inbox collaborators | | Configuration | account settings, inboxes, webhooks, automation rules, macros, audiences, WhatsApp templates | | Conversations | conversation deletions, message deletions | Each entry carries the acting user's name and email, the action, the object's id, the time, and — for the objects that are version-tracked — the attributes that changed. Two entries surprise people. An agent switching between online, offline and busy is recorded, which makes Agents the noisiest family by far. And a template submission to Meta is recorded as a template update, because that is what it is here — see the template lifecycle. What is not recorded This is the more useful list. Nothing below leaves an entry: - Reading anything. There is no record of who opened a conversation, a contact or a report. - Messages sent, conversations assigned, resolved, snoozed or labelled, macros run. - Contacts created, edited, merged or deleted; imports and bulk actions. - Campaigns — created, edited or sent. See WhatsApp campaigns. - Canned responses, custom attributes, custom roles. - Commerce store connections and order actions, and flow changes, are written to the same table, but the page has no label or filter for them, so they appear in the list without a description. IP address and location By default the last part of each IP address is masked, and a Location column shows a city and country where your installation looks those up. On installations with the extra IP-address feature enabled, the column shows the full address instead. There is no setting for this inside your account. Who can read it Administrators only, and only where the feature is enabled. Audit logs are a paid capability and are off by default, so on many accounts the page is simply absent. The permission list for custom roles has no entry for audit logs, so this cannot be delegated — see roles and permissions. Entries are still written while the feature is off. Switching it on later reveals the history that accumulated in the meantime. How long it is kept One year by default. Entries older than the retention window are removed by a scheduled sweep. The window is an installation-wide setting that only the people who run your Lynomia Chat server can change, and the minimum it accepts is 30 days. It is not a plan feature and no administrator, agent or account setting affects it — so if you need a different window, ask whoever operates your installation. Within the window, nobody — including an administrator — can edit or delete an entry from the product. The sweep is the only thing that removes one, it only ever removes entries past the window, and it always errs on the side of keeping an entry slightly longer rather than slightly less. If you need a record for longer than the window, keep it outside the product. There is no export (see Limits below), so that means recording what you need at the time you read it. A worked example A WhatsApp number stops receiving on a Thursday. An administrator opens Settings → Audit Logs, filters to Inboxes, and sets the date range to the last two days. One entry shows a colleague updated that inbox on Wednesday evening. The entry lists the attributes that changed, which is enough to know what to put back. The conversations lost while the inbox was misconfigured are not in the audit log and are not recoverable — see when WhatsApp does not work. Steps 1. Go to Settings → Audit Logs. 2. Narrow by event type, by date range, or by searching for a person's name or email. Search needs at least three characters. 3. Sort newest or oldest first. The list is paginated at 25 entries a page. Limits - No export. No CSV, no download, no export button. What you can do is read, filter and page through entries in the browser. - One event type at a time in the filter. - You cannot search by object. Search matches the acting user's name, username or email, not an inbox name or a conversation id. - Deleted messages show no content. The deletion is recorded; the text is deliberately withheld from the list. - A conversation deletion records only that it happened, not the conversation's contents. - A deleted user's entries remain, shown by the email recorded at the time, so an entry can name somebody who no longer has an account. - The log answers "what changed", not "why". There are no comments or annotations. Related - The record of your imports - Roles and permissions - Teams and agents - Set up an inbox - When something is not working If it does not work Audit Logs is not in Settings. Either you are not an administrator, or the feature is not enabled for your account or your installation. The page is empty. No recorded event has happened yet in the range you are looking at. Clear the filters first — a date range and an event type both narrow the list. Some entries have no description. Those are the Commerce and flow events mentioned above. The entry is real; the page has no sentence for it. The action I need to prove is not there. Check the "what is not recorded" list before concluding something was hidden. Most day-to-day work is deliberately not audited.

Integrations

Slack

The Slack integration mirrors your conversations into one Slack channel. Each conversation becomes a thread, and every message in it — incoming, outgoing, private notes and activity lines — is posted into that thread as it happens. What makes it worth a decision rather than a click is the thread behaviour setting. In one mode a reply typed in the Slack thread is sent to the customer. In the other it never leaves Slack. Choosing wrong is how a manager's aside reaches a customer. When to use it When the people who need to see customer messages already live in Slack and will not open a second tool — an operations team, a shift manager, a founder. It is also the cheapest way to give somebody visibility without giving them an account. When not to use it - As your team's main inbox. Assignment, labels, priorities, macros, canned responses, templates and reports exist in the inbox and not in Slack. A thread is a copy, not a workspace. - To route conversations to different teams. There is one channel for the whole account. You cannot send the sales inbox to #sales and support to #support. - For WhatsApp beyond the 24-hour window. A reply typed in Slack is an ordinary message. If the window has shut, it will not be delivered, and Slack is not where you will notice. What you need first - An administrator account. - Your installation must have Slack credentials configured. If it does not, Slack is simply absent from Settings → Integrations — see integrations. - Permission to install a Slack app in your workspace. - If you want a private channel, add the app to that channel in Slack first. The connect step joins public channels for you; it cannot join a private one it has not been invited to. Steps 1. Go to Settings → Integrations → Slack and start the connection. Slack asks you to authorise the app for your workspace. 2. You come back with the workspace linked and the integration inactive. This is expected: a workspace is not a destination. 3. Choose Connect channel and pick the channel from the list. Public and private channels are both listed; archived channels are not. 4. Choose the Slack thread behaviour. You can change this later without reconnecting. A public channel is joined automatically when you pick it. The integration becomes active at that point, not before. The two modes | | Two-way sync | Alerts only | |---|---|---| | Conversations posted to the channel | yes | yes | | A reply typed in the thread | sent to the customer | stays in Slack, always | | note: prefix needed to stay internal | yes | no — nothing escapes | | What the thread is for | answering | discussing | Pick Alerts only whenever the people in that channel are not the people who answer customers. It is the safe default for a visibility channel, and it is the only configuration in which a careless message in the thread cannot reach a customer. Pick Two-way sync only if those people are your agents and understand that the thread is a reply box. Replying from Slack In two-way sync: - Reply in the thread, not in the channel. A new channel message is not attached to any conversation and is ignored. Only replies inside a conversation's thread are read. - Start the message with note: or private: to make it a private note instead of a reply to the customer. The prefix is checked at the start of the message, case-insensitively. - Files posted in the thread are picked up; edits, reactions, joins and other Slack message subtypes are not. - Messages posted by apps and bots are ignored, which is what stops a Slack workflow from answering your customers. Whose name the reply carries This is worth getting right before you switch two-way sync on. | The Slack author | How the customer sees it | |---|---| | Has a Lynomia Chat profile with the same email address | as that agent | | Does not | as the integration's own bot profile, carrying their Slack display name and avatar inside Lynomia Chat | So a person replying from Slack under a different email is not impersonating anyone, but the customer does not see a named agent either. If you want attribution, match the email addresses. What a thread looks like The first post for a conversation carries the context you need to act: the inbox name and type, a link to the conversation in Lynomia Chat, and — on an email inbox — the subject line. Later posts in the thread are just the message. Two formatting details, because they are easy to misread: - A private note appears in the thread prefixed private:. - An activity line — an assignment, a status change — appears in italics. A worked example A Kuwait retailer wants its operations team watching WhatsApp without replying by accident. An administrator connects Slack, picks #support-watch, and sets the behaviour to Alerts only. Conversations now arrive in that channel as threads. The shift manager reads them and discusses a difficult one in the thread; the customer sees none of it. When a decision is made, the manager opens the conversation from the link in the thread and the agent answers in the inbox. Replies and notes made there keep appearing in the Slack thread, so the channel stays current. Who can do this Administrators only. The custom role permission list has no entry for integrations, so this cannot be delegated — see roles and permissions. Limits - One Slack connection per account, and one channel. To change channel, update the selection; to change workspace, delete the integration and connect again. - An agent's reply does not start a thread. A thread exists once the conversation has been posted; a conversation that has never had an incoming message has nothing to attach to. - Only thread replies are read. Channel-level messages are ignored. - No reactions, no edits, no deletions. Editing a Slack message does not edit the customer's copy, and deleting it does not unsend anything. - No per-inbox routing and no filtering. Every conversation in the account goes to the channel. - Deleting the integration removes the link, not the history. The threads stay in Slack; they simply stop updating. - The connection can expire. When it does, the integration shows that attention is required and the fix is to delete it and connect the workspace again — there is no silent re-authorisation. - Tweets are excluded on a connected Twitter profile; everything else is posted. Related - Integrations · Webhooks · Dashboard apps - Work in the inbox - The WhatsApp 24-hour window - Roles and permissions If it does not work Slack is not listed under Integrations. Your installation has no Slack credentials configured. Nothing in your account turns this on. The integration says it is inactive. You linked the workspace but have not picked a channel. Choose Connect channel. My private channel is not in the list, or picking it does nothing. Add the app to that channel in Slack first, then try again. A private channel cannot be joined for you. Conversations arrive but my replies do not reach the customer. Either the behaviour is set to Alerts only, or you replied in the channel instead of inside the thread, or your message began with note:. My replies reach the customer as a bot. Your Slack account's email does not match a Lynomia Chat profile. Fetching channels failed. Try again — a large workspace is paged through in several requests, and a transient Slack error fails the whole fetch rather than half of it. It stopped working after a while. Look for the expiry notice on the Slack page. Delete the integration and connect the workspace again.

Integrations

Settings → Integrations is a catalogue of apps you can connect your account to. Ten exist in the product. Your page will usually show fewer, because several are switched on by whoever runs your installation rather than by you. Two things that feel like integrations are not on this page. Connecting a store is its own section — see what connecting a store gives you. Bots live under Automation — see agent bots. What exists | App | What it does | Connected per | |---|---|---| | Webhooks | posts account events to a URL you own | account, as many as you want | | Dashboard Apps | shows a web page of yours as a tab next to the conversation | account, as many as you want | | Slack | mirrors conversations into one Slack channel | account, one | | Dialogflow | lets a Google Dialogflow agent answer in one inbox | inbox, one per inbox | | Google Translate | translates one message on demand, and records the language the customer wrote in | account, one | | OpenAI | holds your own OpenAI key for the AI writing features, and turns label suggestions on | account, one | | Cloudflare RealtimeKit | starts a video or voice call from inside a conversation | account, one | | Linear | creates a Linear issue from a conversation, or links an existing one | account, one | | Notion | gives the AI assistant read access to your Notion content | account, one | | LeadSquared | creates leads and logs conversation activity in LeadSquared | account, one | Which of them you will see The list is filtered before it reaches you, so a missing app is not a fault. | App | Shown when | |---|---| | Webhooks, Dashboard Apps, Dialogflow, Google Translate, OpenAI, Cloudflare RealtimeKit | always | | Slack | your installation has Slack credentials configured | | Linear, Notion | your installation has credentials and the feature is on for your account | | LeadSquared | the CRM feature is on for your account | Nothing in your account turns these on. If an app you need is absent, that is a conversation with whoever runs your installation. The three worth a sentence each Slack has two modes. Two-way posts conversations into the channel and sends replies typed in the Slack thread back to the customer. Alert posts them and sends nothing back — the thread is a notification, not a reply box. Pick alert if people in that channel are not meant to answer customers. A dashboard app is an iframe, not a plugin. You give it an HTTPS URL. It appears as a tab beside the conversation, and the page is sent the current conversation, the contact, your account's custom attribute definitions, the signed-in agent and the current theme. What it does with them is your code's business. Google Translate does two separate things. It detects the language of the customer's first incoming message and stores that on the conversation. Separately, it gives every message a Translate action, which translates that one message into a language you pick. It does not translate the conversation as you read it, and it does not translate what you send. What you need first An administrator account. Every page under Integrations is administrator-only. A worked example A Kuwait retailer wants its operations team notified in Slack without them replying to customers by accident. An administrator connects Slack, picks the #support-watch channel, and sets the mode to Alert. Conversations now appear in that channel as they arrive. A manager replying in the Slack thread changes nothing — the customer never sees it, and the team answers in the inbox as before. Who can do this Administrators only. The custom role permission list has no entry for integrations, so this cannot be delegated — see roles and permissions. Limits - One connection per app, except Webhooks and Dashboard Apps (as many as you like) and Dialogflow (one per inbox). - There is no generic connector for other tools. The way to reach anything not on this list is webhooks, or the webhook action inside an automation rule or a flow. - The OpenAI entry is a key, not a feature. It supplies the credential the AI writing features use and switches label suggestions on. It does not add anything by itself. - Language detection runs once per conversation, on the first incoming message, and is skipped if the conversation already has a language recorded. - Dialogflow is per inbox. A bot connected to one inbox does nothing in another, an inbox already connected is not offered again, and email inboxes cannot be connected at all. - WooCommerce, Salla, Zid and Shopify are not on this page at all. They are Commerce platforms — see what each platform supports. Related - Webhooks · Slack · Dashboard apps - What connecting a store gives you · Connect Shopify - Agent bots · Automation rules - Roles and permissions If it does not work The app I want is not listed. It is not switched on for your installation. The table above says what each one needs. Integrations is not in Settings at all. You are signed in as an agent, or with a custom role. The page is administrator-only.