Results and approval
Handing your product copy to a language model and hoping for the best is not a plan. This screen is the reason you do not have to.
Every value a profile generates is listed here, side by side with the original, and you have the final word on all of it. Read it, filter it, approve it in bulk, override a sentence you disagree with, or throw the lot away and start over. Nothing reaches a feed that you did not allow.
Open it with the Results button on the profile form, or the Results row action in the profile library. The page is titled AI optimization results: profile name and is always scoped to a single profile.
The results grid
| Column | Description |
|---|---|
| Entity | The product's SKU. A product that no longer exists is shown as #id. |
| Store view | Hidden by default; enable it in the Columns control. Values are generated per store view. |
| Attribute | Which attribute this row fills. An enrichment profile produces one row per declared output. |
| Original | The product's own value, as it was when the value was generated. |
| Optimized | What the model produced. This cell is editable - see Editing a value by hand. |
| State | See the table below. |
| Tokens | Hidden by default. How many tokens this row cost. |
| Updated | When the row last changed. |
The search box above the grid searches SKUs and both text columns, and the State filter narrows the grid to one state.
States
| State | Meaning |
|---|---|
| Live | The value is generated and your feeds are using it. |
| Awaiting approval | Generated under manual approve mode and not yet approved. Your feeds keep using the previous value. |
| Failed | Generation failed. The reason is shown beneath the badge, and the item is retried by a later run. Your feeds emit the raw product value meanwhile. |
| Edited by you | You overrode the generated text. The model will not touch this row again until you clear the override. |
| Kept original | The fill mode left the product alone, because it already had a value. |
| Not in the product data | The model was asked but the product data does not answer the question. This is a normal outcome, not a failure - a profile that invented a value here would be worse than one that left it empty. |
Approve mode
A profile's Approve mode (in its Advanced section) is the safety catch. It decides what happens to a value the moment it is generated.
- Auto - publish generated values immediately. Values go live as they are produced. Right for bulk work you already validated with a preview, and for anything low-risk like filling an empty
material. - Manual - hold generated values for approval. New text waits for you, and your feeds keep serving the previous value in the meantime. Nothing you have not read reaches a marketplace.
Manual is the mode to use on product titles the first time round. Once you trust the profile, switch it to auto and stop thinking about it.
Switching a profile from manual to auto promotes everything currently pending, once, at save time.
Approving
- Approve - a row action, and a mass action for a selection.
- Approve All Pending (n) - a page button that appears whenever anything is pending. It asks to confirm: Publish all n pending value(s)? Your feeds will use them on the next generation.
Approved values take effect the next time the feed is generated.
Generating on demand
Generate Now runs one bounded batch immediately, through the same engine the cron job uses. It is meant for checking that a profile behaves, not for working through a catalog - the background process is what does that.
Afterwards the extension reports what happened, for example:
Generated 10 value(s) for "Title - Google Shopping" using 3,420 token(s). This was one batch, not the whole profile. 240 product(s) are still pending - click again for the next batch, or leave them to the background process.
If everything in scope already has a current value, it says so and spends nothing.
Editing a value by hand
Disagree with one title? Click the Optimized cell and type over it.
Your text is saved as an override: it goes live immediately, and the model will never touch that row again while the override stands. No settings, no exceptions list, no fighting with the prompt to protect one product - you just write what you want and it stays written.
- Clear override removes your text and lets the model generate the value again on the next run.
- Re-optimize queues a row for regeneration. It deliberately skips overridden rows - clear the override first, otherwise nothing is queued.
Both are available as row actions, and Re-optimize also works as a mass action.
Deleting values
Delete removes stored values. Deleted rows are regenerated by the next run; until then your feeds emit the raw product values.
Clear Values wipes everything the profile has stored, after a confirmation that tells you exactly what it will cost:
Delete n stored value(s)? Your feeds will emit the raw product values until the profile regenerates them. Regenerating them is estimated at about n tokens, based on this profile's own average. Your n edited value(s) are kept unless you choose to delete them too.
Your own overrides are kept by default; the dialog offers a checkbox to delete them as well.
Cached category answers are shared between all category-mapping profiles. Clearing one profile's values makes every other mapping profile pay to look its categories up again.
Clear Values is also the way to force a regeneration after a change the extension cannot detect - a renamed category, or an edited dynamic attribute that the prompt reads. See Saving changes to a running profile.
What gets regenerated, and when
You set a profile up once and it keeps itself current - that is the point of a profile rather than a one-off batch job. Edit a product and its value is regenerated automatically. Leave it alone and nothing is re-sent, so a catalog that is not changing costs you nothing to keep optimized.
The background process works through pending items in a fixed priority:
- Never generated - products with no value at all.
- Profile changed - a profile edit invalidated the stored values.
- Product changed - the product row changed since the value was generated.
- Failed - retried, but only once there is no fresh work left.
Failed items therefore never crowd out first-time coverage. A product whose data has not changed is never re-sent, so a stable catalog costs nothing to keep optimized.