Adobe Target Coworker: Review my live tests button

Adobe Target 26.11.1, released on 12 November 2026, puts two Coworker entry points into the Activities list: a Review my live tests button and an Ask Coworker menu on each activity. They only show up if your organization has access to Coworker. For teams that do, the Activities list becomes the place where you can ask for a second opinion on running tests without leaving the page.

It's a small interface change with a bigger process question attached. Who is allowed to ask, what happens with the answer, and who signs off before anything in a live test changes? This post covers those questions.

Key takeaways

• Release 26.11.1 (12 November 2026) adds a Review my live tests button and an Ask Coworker menu for each activity in the Activities list.
• The buttons appear only for organizations with access to Coworker, so check entitlement before planning around them.
• The notes describe two jobs: reviewing your live activities, and answering questions about one specific activity.
• The quality of any answer will depend on how clearly your activities are named, scoped and documented, so tidy those first.
• Write a short team rule covering who can use the entry points, what counts as evidence, and who approves a change.
• Earlier fixes from 13 October 2026 and 15 October 2026 deserve a quick audit at the same time.

What did Adobe Target 26.11.1 change in the Activities list?

The release notes list one item under Activities for 26.11.1, dated 12 November 2026. The Activities list now includes a Review my live tests button and an Ask Coworker menu for each activity. The stated purpose is to have Coworker review your live activities, or answer questions about a specific activity.

That is the whole of what the notes commit to. Two details are worth reading closely.

First, the button is phrased around live tests. It is a prompt to look at what is running right now, which is a different job from helping you build something new. Second, the menu is per activity, which means the question you ask is anchored to one row in the list rather than to your whole account.

What the notes do not say matters just as much. They don't say what Coworker looks at when it reviews an activity, what form the answer takes, or whether it can act on anything. Don't assume it can edit, pause or approve. Assume it reads and answers, and confirm the exact scope in Adobe's own Coworker documentation, which the release note points to.

Who will actually see Review my live tests?

Only people in organizations that have access to Coworker. The notes are explicit about that condition. If your Activities list looks the same on Monday as it did last week, that's the likely reason, and nothing is broken.

That splits readers into three groups:

• Teams with access. You get the new controls now. The work is deciding how to use them without creating a second, informal approval path.
• Teams without access. Nothing changes in your interface. The useful thing to take from this release is the review checklist further down, which works with or without an assistant.
• Teams unsure. Ask your Adobe administrator or account contact whether Coworker is enabled for your organization. Don't guess from one user's screen, since what an individual sees may differ from the organization's entitlement.

If you manage an agency or a shared services team that supports several brands, check each organization separately. Access is described at the organization level, and brands under different organizations can differ.

What should be in order before you ask Coworker about a live test?

An assistant that answers questions about an activity can only work from what the activity itself says. If your activity is called 'Test 2 copy' with a goal nobody remembers choosing, a review won't rescue it. A person who reads it would struggle too.

So before you press anything, spend an hour on hygiene. Walk the Activities list and check these for each live test:

1. Name and purpose. Can a new colleague tell from the name what the test is for? Rename the ones that can't, using whatever convention your team already follows.
2. Hypothesis. Is there a written statement of what you expect to change and why, stored somewhere your team actually looks?
3. Primary goal. Is there one clear success metric, and does it match what the business cares about rather than what was easiest to track?
4. Audience and targeting. Are the conditions still what you intended, or did someone widen them during a rush?
5. Owner and end date. Does the test have a named owner and a planned stop point? Tests without either tend to run for months.

This isn't glamorous work. It is what turns a review from a generic summary into something you can act on.

What questions are worth putting to a specific activity?

The Ask Coworker menu is most useful when your question is narrow. Broad requests like 'is this test okay?' invite broad answers. Specific ones are easier to check.

Good prompts for a single live activity tend to fall into a few families:

• Setup sanity. Ask what the activity is configured to do, in plain language, and compare the answer with what you meant. If the two don't match, you've found a configuration problem or a documentation gap, and either is worth knowing.
• Goal and audience fit. Ask whether the stated goal and audience line up with the hypothesis you wrote down.
• Reading the results page. If the answer includes interpretation of results, treat it as a starting point for your analyst, not a conclusion. Statistical significance, sample sizes and novelty effects still need a human who understands your traffic.
• Hand-off questions. Ask it to explain an inherited activity before you take over its ownership. This is probably the most underrated use, since inherited tests are where the surprises live.

Whatever you ask, write down the question and the answer next to the activity. If you act on it, you'll want a record of why.

How should you roll out the Coworker entry points on your team?

Start small, and name an owner. A controlled rollout takes about two weeks and avoids the situation where five people each ask different questions of the same live test and come away with five different stories.

The table below is a starting checklist. Adjust the owners to your own structure.

Step	What to do	Suggested owner
Confirm access	Check with your Adobe administrator that Coworker is enabled for your organization	Target admin
Pick a pilot	Choose two or three live activities that are well documented and low risk	Optimization lead
Set the rule	Write one paragraph: who may ask, what gets logged, who approves changes	Optimization lead and governance owner
Run reviews	Use Review my live tests and the Ask Coworker menu on the pilot activities	Pilot users
Verify	Compare each answer with the activity settings and your own notes	Analyst
Decide	Keep, adjust or drop the practice, and widen to other users if it helped	Optimization lead

Two things to keep from the start. Keep the rule short enough that people read it. And keep change approval exactly where it is today. A review that suggests a change doesn't replace your QA step, your stakeholder sign-off or your release calendar.

How do you measure whether it is helping?

Don't look for a headline number. Adobe hasn't published figures on this feature in the release notes, and you shouldn't expect one. Measure what matters inside your own program, using signals you already collect.

A few that are worth tracking over a month or two:

• Time to understand an inherited activity. Note how long a new owner takes to explain a live test to the team, before and after using Ask Coworker as an aid.
• Issues found in live tests. Count the misconfigurations or stale tests you catch, and note whether the review or a person found them.
• Wrong or unhelpful answers. Keep a simple tally of answers your analyst had to correct. If the tally is high, tighten your naming and documentation, or narrow how you use the feature.
• Reviews that led to a change. Of those, how many went through your normal approval and QA? The answer should be all of them.

If after a month you can't point to a single case where the review saved time or caught something, that's a legitimate result. Switch to using it occasionally and move on.

What should you avoid doing with these entry points?

A few things are easy to get wrong.

Don't treat the answer as approval. A review is input. The person who owns the test owns the decision. If something goes wrong in a live activity, 'the assistant said it was fine' won't help anyone.

Don't make assumptions beyond the notes. The release notes say the controls review live activities and answer questions about an activity. They don't describe editing, pausing, scoring or ranking. Don't build a process that depends on capabilities nobody has confirmed.

Don't paste sensitive data into questions without checking policy. If your organization has rules about customer data, internal strategy or unreleased campaign details, apply the same rules here. Check how Adobe documents data handling for Coworker, and involve your privacy or security team if it's unclear.

Don't let it replace the analyst. Experiment design, sample size, segment overlap and result interpretation need someone who knows the business. The button can speed up the first read. It can't own the conclusion.

Don't skip the housekeeping. The reason to tidy names, goals and owners isn't to impress an assistant. It's that unclear tests cost you regardless.

Do you need an implementation partner for this?

For the Coworker controls themselves, probably not. Turning on the practice is mostly a governance and habit change. Your own optimization lead, an analyst and your Adobe administrator can handle access, a pilot and a one-paragraph rule.

A partner earns their fee in the surrounding work. Examples include auditing a backlog of inherited activities, designing a naming and documentation standard, setting up a review cadence that fits your release calendar, and checking that your reporting stack, including Analytics for Target, is configured cleanly. If your team is thin or your program has grown without much structure, outside help can shorten the cleanup. You can browse Adobe Target implementation partners to see who works in this area, or compare options through the top Adobe Target partners listing.

If you do go to market, brief clearly. The Adobe Target RFP template is a reasonable starting point for scoping an audit or a program-health review, and it helps you ask for the same things from every vendor.

Which earlier Target fixes are worth checking at the same time?

The 26.11.1 entry is the newest item, but the two October releases include fixes that touch the same Activities and reporting areas. A short review pass is cheap and may surface things your team has been working around.

From the 15 October 2026 release (26.10.2):

• The Overview page of an activity could show incorrect goal settings, for example adding https:// to the page URL and omitting the URL contains condition, even though the real goal configuration was correct. If anyone on your team lost trust in that page, tell them it's fixed.
• Editing a promotion in a live Recommendations activity could cause Target to create new promotions and recommendation units even when nothing changed in their definition. If you edited live promotions before this fix, look for stray duplicates.
• Reporting presets saved for an activity were being deleted automatically after about two weeks. If your analysts have been rebuilding presets, they can stop.
• Safari is now supported in Target. The Visual Experience Composer and Enhanced Experience Composer are not supported in Safari, and the VEC now shows an overlay telling users to switch to Chrome. Tell your Safari-based colleagues so they aren't surprised.

From the 13 October 2026 release (26.10.1):

• A4T reports for activities using a newly added report suite could show a 'Something went Wrong' error, and View in Analytics could show an 'Incompatible report suite' message. If you hit that on a new report suite, it was a known issue that has been fixed.
• The Modifications panel could show raw HTML instead of the offer name for Experience Fragments delivered through an mbox. That's fixed too.

The notes also carry a time-sensitive item about the deprecation of the Target UI version toggle, with a pointer to Adobe's Target UI update FAQs. The notes give no date in the text, so read the FAQs and check whether anyone on your team still relies on the older interface.

None of this is dramatic. Together it makes a sensible afternoon of housekeeping to pair with your Coworker pilot, and it keeps your live tests easier for anyone, human or otherwise, to read.

For more release breakdowns, see the MarTech Partners blog.

Sources

• Adobe Experience League: Target release notes — Release 26.11.1 (12 November 2026) for the Coworker entry points; 26.10.2 (15 October 2026) and 26.10.1 (13 October 2026) for the related fixes and Safari support.