Could an AI Assistant Safely Create a Marketo Program?

The nine steps below turn the five stages into an implementation. Steps 1 to 4 are about Marketo and the integration layer, Steps 5 to 7 are about the Microsoft side, and Steps 8 and 9 are about verification, audit and rollout.

About navigation labels: Marketo menu paths below are taken from Adobe’s documentation where cited. Microsoft is actively changing the Copilot Studio interface (in 2026 it introduced a new agent experience and “workflows” alongside agent flows), so Microsoft steps are described by function, with labels only where Microsoft’s current documentation confirms them. Always test in a sandbox or development environment first.

Step 1: Prepare Marketo for governed automation

Objective: Give the automation a safe, predictable place to work: approved templates, a target folder structure, a naming convention, and an API user with the minimum permissions it needs.

Prerequisites: Marketo admin access; agreement from marketing operations on templates and naming; ideally a Marketo sandbox instance for development.

Navigation: Marketing Activities (templates and folders); Admin > Users & Roles (role and API-only user); Admin > Integration > LaunchPoint (custom service); Admin > Integration > Web Services (REST endpoint and identity URL) (Adobe, Authentication).

Detailed instructions:

1. Create or confirm your template programs. For each program type you want the assistant to support (start with one, such as webinars), make sure a reviewed template exists in each workspace that will use it. Remember that the clone API cannot copy across workspaces, so an EMEA template is needed for EMEA programs.
2. Name templates so they are easy to recognize, for example TPL_Webinar_v3, and keep them in a dedicated templates folder that only marketing operations can edit.
3. Make the template “clone-ready”. Remove anything the clone API cannot handle (push notifications, in-app messages, reports, social assets). Leave all smart campaigns inactive. Use tokens such as {{my.WebinarTitle}}, {{my.EventDate}} and {{my.Language}} in emails and landing pages, so a new program only needs token values.
4. Create target folders where prepared programs will land, for example EMEA > Germany > 2026 > Webinars. Note the folder IDs (the ID appears in the URL when you select the folder, and can also be retrieved with GET /rest/asset/v1/folder/byName.json).
5. Write down the naming convention as a pattern code can check. This article uses YYYY-MM_CC_TYPE_Short-Name, for example 2026-11_DE_WBN_AI-in-Manufacturing.
6. Create a role for the integration. In Admin > Users & Roles, create a role that grants only the asset read and write permissions the workflow needs from the Access API permission group. Do not grant lead, list or campaign execution permissions the workflow does not use. Permission names can vary slightly between instances, so review the Access API list carefully.
7. Create an API-only user with that role, assigned only in the workspaces the assistant will serve. Adobe’s REST API guide describes creating a user with the API Only option and assigning a role (Adobe, REST API).
8. Create a LaunchPoint custom service for the API-only user. Copy the Client ID and Client Secret straight into your secrets vault.

Example configuration (illustrative):

Expected result: a template you trust, a folder to clone into, and credentials stored in a vault.

How to verify: request an access token from the identity endpoint and call GET /rest/asset/v1/program/byName.json?name=TPL_Webinar_v3. You should receive the template’s details. Then try reading a program in a workspace the role does not cover: it should not be returned.

Common mistakes: reusing an admin user’s credentials for the integration; giving the API role every permission “to be safe”; keeping templates in a folder anyone can edit.

Troubleshooting: a 603 error means the role lacks permission for that API. Empty results for assets you know exist usually mean the API user is not assigned to that workspace.

Visual requirement: a screenshot from your own instance of the templates folder and the role’s Access API permissions (do not use mock screenshots).

Step 2: Define the request schema the AI must produce

Objective: Turn a free-text request into a fixed, validated structure. This is the contract between the AI and everything after it.

Prerequisites: the template registry from Step 1.

Navigation: your integration layer’s code repository.

Detailed instructions:

1. List the fields a program request needs. Keep the list short; every extra field is another thing the AI can get wrong.
2. Separate fields the AI extracts (country, program type, short name, launch date, token values) from fields the platform supplies (the requester’s identity, taken from their signed-in account, never from the chat text).
3. Exclude anything the rules should derive: the final program name, folder ID, workspace and template ID are calculated by code from the registry.
4. Write the schema down, for example as JSON Schema, and use it both in the agent’s instructions and in the integration layer’s input validation.

Example configuration:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "MarketoProgramRequest",
  "type": "object",
  "required": ["country", "program_type", "short_name", "launch_date", "tokens"],
  "additionalProperties": false,
  "properties": {
    "country":      { "type": "string", "pattern": "^[A-Z]{2}$", "description": "ISO 3166-1 alpha-2 code, e.g. DE" },
    "program_type": { "type": "string", "enum": ["webinar"] },
    "short_name":   { "type": "string", "minLength": 3, "maxLength": 60 },
    "launch_date":  { "type": "string", "format": "date" },
    "tokens": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "my.WebinarTitle": { "type": "string", "maxLength": 200 },
        "my.EventDate":    { "type": "string", "format": "date" },
        "my.Language":     { "type": "string", "enum": ["de", "en", "fr"] }
      }
    }
  }
}

Expected result: a schema that rejects anything outside the supported scope (for example, a “nurture” request when only webinars are enabled).

How to verify: run the schema against a handful of test requests, including incomplete and out-of-scope ones, and confirm they fail with clear messages.

Common mistakes: letting the AI supply the requester’s identity; adding a free-text “notes” field that later gets copied into Marketo unchecked.

Troubleshooting: if the agent keeps producing values the schema rejects, show it the allowed values (enums) in its instructions, and ask it to confirm uncertain fields with the user instead of guessing.

Visual requirement: a simple diagram of “AI-extracted fields” versus “platform-supplied fields” versus “rule-derived fields”.

Step 3: Encode the governance rules

Objective: Make every validity decision deterministic, testable and owned by marketing operations.

Prerequisites: the naming convention, template registry and workspace permission model.

Navigation: integration layer code (the validate_request function in the appendix).

Detailed instructions:

1. Template check: is there an approved template for this country and program type? If not, stop.
2. Permission check: is the signed-in requester allowed to create programs in the template’s workspace? In production, read this from identity groups (for example Microsoft Entra ID security groups), not a hard-coded list.
3. Date check: is the launch date valid and far enough away to allow review? The example uses a 14-day minimum lead time; use your own.
4. Name generation: build the program name from the validated fields, then check it against the naming pattern and the 255-character limit.
5. Uniqueness check: call GET /rest/asset/v1/program/byName.json to make sure the name is not already taken.
6. Channel check: confirm the template’s channel exists (GET /rest/asset/v1/channels.json) and matches the program type, because channel cannot be changed after creation.
7. Token check: all required tokens are present, and no unexpected tokens are included.
8. Return a plan, not an action: a valid/invalid flag, a list of human-readable issues, the program name and a plan ID (a hash of the exact plan) that the approval will refer to.

Example configuration (excerpt from the reference code):

def validate_request(req: ProgramRequest, today: date | None = None) -> Plan:
    today = today or date.today()
    issues = []

    template = TEMPLATE_REGISTRY.get((req.country.upper(), req.program_type.lower()))
    if not template:
        issues.append(f"No approved template for country '{req.country}' and type '{req.program_type}'.")
        return Plan(valid=False, issues=issues)

    allowed = WORKSPACE_PERMISSIONS.get(req.requester.lower(), set())
    if template["workspace"] not in allowed:
        issues.append(f"{req.requester} is not permitted to create programs in workspace '{template['workspace']}'.")

    launch = date.fromisoformat(req.launch_date)
    if (launch - today).days < MIN_LEAD_TIME_DAYS:
        issues.append(f"Launch date {launch} is less than {MIN_LEAD_TIME_DAYS} days away.")

    name = build_program_name(req, template["type_code"])   # the AI never writes the final name
    if not NAME_PATTERN.match(name):
        issues.append(f"Generated name '{name}' does not match the naming convention.")
    ...

Expected result: for the same input, the rules always give the same answer, with reasons a marketer can understand.

How to verify: write unit tests for each rule, including the failure cases. The reference code ships with offline tests that check, among other things, that a requester without workspace access, a launch date inside the lead time, missing tokens and unexpected tokens are all rejected.

Common mistakes: asking the AI whether a name “looks compliant”; spreading rules across flows, prompts and code so nobody knows which one wins.

Troubleshooting: if marketers often fail a rule, the rule may be wrong or badly explained. Review the audit log for the most common rejection reasons each month.

Visual requirement: a decision tree showing the checks in order, with a stop at each failure.

Step 4: Build the integration layer’s create, verify and audit functions

Objective: Create the program from the approved template, set its tokens, prove the result is correct, and record everything.

Prerequisites: Steps 1 to 3; a hosting option (for example Azure Functions or Azure Container Apps) with managed identity access to your secrets vault; Python 3.10+ and the requests library for the reference code.

Navigation: integration layer code and hosting configuration.

Detailed instructions:

1. Authenticate correctly. Request a token from <identity URL>/oauth/token with the client credentials grant, cache it, refresh it before it expires (tokens last 3,600 seconds), and send it as Authorization: Bearer <token> (Adobe, Authentication).
2. Handle Marketo’s error model. Read success and errors in every response. Re-authenticate on 601 or 602. Back off and retry on 606 (rate limit), 615 (concurrency), 604 and 608. Fail clearly on everything else (Adobe, Error codes).
3. Re-validate at execution time. Between approval and execution, a name may have been taken or a permission removed. Run the plan again and compare its plan ID with the one that was approved. If they differ, stop.
4. Clone the template with POST /rest/asset/v1/program/{templateId}/clone.json, sending the generated name, the target folder as {"id": 2050, "type": "Folder"} and a description that records the requester, approval reference and correlation ID.
5. Set tokens with POST /rest/asset/v1/folder/{programId}/tokens.json and folderType=Program, one call per token, using the right token type (for example date for dates).
6. Verify (see Step 8) and write audit records for the plan, the clone and the verification.
7. Return a structured result to the flow: status (prepared or needs_attention), program ID and name, each check with pass or fail, and the list of manual steps.

Example configuration (excerpt):

def execute_plan(req, client, approved_plan_id, approval_ref):
    correlation_id = str(uuid.uuid4())
    plan = plan_program(req, client)                 # fresh validation, including name uniqueness
    if not plan.valid:
        return {"status": "rejected", "issues": plan.issues, "correlation_id": correlation_id}
    if plan.plan_id != approved_plan_id:             # the approval covers this exact plan only
        return {"status": "rejected", "issues": ["Request changed after approval. Submit it again."]}

    tpl = plan.template
    created = client.clone_program(tpl["template_program_id"], plan.program_name, tpl["target_folder_id"],
                                   f"Prepared by AI assistant for {req.requester}. Approval ref {approval_ref}.")[0]
    for token_name, value in req.tokens.items():
        client.set_program_token(created["id"], token_name, value, "date" if token_name == "my.EventDate" else "text")

    verification = verify_program(client, created["id"], plan, req)
    audit("program_verified", correlation_id=correlation_id, program_id=created["id"], passed=verification["passed"])
    return {"status": "prepared" if verification["passed"] else "needs_attention", "program_id": created["id"],
            "program_name": plan.program_name, "verification": verification, "correlation_id": correlation_id}

The complete, commented file, including the Marketo client with token caching and retries, is in the appendix.

Expected result: a cloned program in the target folder, tokens set, and a verification report.

How to verify: run the offline tests first. Then, in a sandbox, run a dry run (plan_program) and a real execution against a test template, and compare the program in the Marketo UI with the verification report.

Common mistakes: passing the access token as a query parameter (no longer supported); ignoring "success": false because the HTTP status was 200; not handling the shared daily quota.

Troubleshooting: see the troubleshooting guide for error codes 601, 602, 603, 606, 607, 615, 709, 710 and 711.

Visual requirement: a sequence diagram of plan, approve, execute, verify, audit.

Step 5: Expose the integration layer to Power Automate

Objective: Give the agent two safe tools, “plan a program” and “execute an approved plan”, through a deterministic flow.

Prerequisites: Power Automate or Copilot Studio access in an environment your admins have approved; an authentication method for the integration layer (for example Microsoft Entra ID OAuth through a custom connector, or Azure API Management); confirmation from your Microsoft licensing admin about which connectors your licenses cover (HTTP actions and custom connectors can require premium licensing).

Navigation: Copilot Studio agent flows, or Power Automate cloud flows. Microsoft documents that agent flows using the When an agent calls the flow trigger can be added to agents as tools, and that agent flow runs consume Copilot Studio capacity (Microsoft Learn, Agent flows).

Detailed instructions:

1. Create a custom connector or an HTTP action that calls your integration layer’s plan and execute endpoints, authenticated with Entra ID. Do not put the Marketo client secret anywhere in the flow.
2. Create flow 1, “Plan Marketo program”, using the When an agent calls the flow trigger. Inputs: the structured request fields. Add the requester’s identity from the authenticated user context rather than from a text input. Call plan. Return valid, issues, program_name and plan_id to the agent.
3. Create flow 2, “Execute approved Marketo program plan”, also triggered by the agent. Inputs: the request fields and plan_id. This flow runs the approval (Step 7) and, only if approved, calls execute.
4. Keep both flows in a solution so they can be versioned and moved between development, test and production environments.
5. Apply your organization’s data policies (Power Platform data loss prevention policies) so the custom connector can only be used in approved environments.

Example configuration (illustrative flow outline):

Flow: Execute approved Marketo program plan
Trigger: When an agent calls the flow
  Inputs: country, program_type, short_name, launch_date, tokens (JSON), plan_id
1. Get requester from the signed-in user context
2. Call integration layer: POST /plan  -> confirm plan_id matches and valid = true
3. Start and wait for an approval  (Approvals connector)
     Title: "Prepare Marketo program 2026-11_DE_WBN_AI-in-Manufacturing"
     Assigned to: requester (confirmation) or regional marketing ops lead (approval)
     Details: plan summary, template, folder, tokens, what will NOT be done
4. Condition: outcome = Approve
     Yes -> Call integration layer: POST /execute (plan_id, approval reference)
     No  -> Return "Not approved" with the approver's comments
5. Return status, program name, verification checks and manual steps to the agent

Expected result: the agent can only plan and execute through these two flows. There is no path from the agent to Marketo that bypasses the integration layer.

How to verify: run each flow manually with test inputs. Then confirm in the integration layer’s logs that requests from the flow carry the expected identity and that an invalid plan returns issues without calling Marketo.

Common mistakes: giving the agent the integration layer’s URL and key directly; storing secrets in flow variables; one flow that both plans and executes without an approval in between.

Troubleshooting: if a flow fails with an authorization error, check the custom connector’s authentication settings and the app registration’s permissions. If runs are blocked, check Copilot Studio capacity in the Power Platform admin center, since Microsoft notes new agent flow runs are blocked when prepaid capacity is consumed (Microsoft Learn, Agent flows).

Visual requirement: a screenshot of the finished flow from your own environment.

Step 6: Design the Copilot Studio agent and conversation

Objective: An agent that understands requests, asks for what is missing, shows the plan back in plain language, and never pretends to have done something it has not.

Prerequisites: a Copilot Studio agent in the same environment as the flows; the flows from Step 5 added as tools; the agent published to Microsoft Teams, which Microsoft lists as an available channel (Microsoft Learn, Channels).

Navigation: your agent’s instructions, tools and channel settings in Copilot Studio.

Detailed instructions:

1. Write focused instructions. Tell the agent its single job, the fields it must collect, the allowed values, and the rules of behavior (see the example below).
2. Add only the two tools. Name and describe them precisely so the agent knows when to use each. Do not add general-purpose Marketo tools to this agent.
3. Require a confirmation turn. After calling “Plan Marketo program”, the agent shows the plan: program name, template, folder, tokens, what will happen and what will not. Only after the user confirms does it call the execute flow.
4. Return results honestly. If verification returns needs_attention, the agent says so and lists the failed checks. It never describes a program as “ready to launch”.
5. Publish to Teams for a small pilot group first.

Example configuration (agent instructions, illustrative):

You help marketers prepare Adobe Marketo Engage programs from approved templates.
Scope: webinar programs only, for countries with an approved template.

1. Collect: country, program type, a short program name, launch date, webinar title, event date, language.
2. If anything is missing or ambiguous, ask. Never guess dates, countries or languages.
3. Call "Plan Marketo program". If the plan is invalid, explain each issue in plain language.
4. If the plan is valid, show the program name, template, destination and token values,
   and state clearly: "I will not activate, schedule or approve anything."
   Ask the user to confirm.
5. Only after explicit confirmation, call "Execute approved Marketo program plan".
6. Report the verification result exactly. List any failed checks and the manual steps.
You cannot activate campaigns, change audiences, edit consent settings or delete programs.
If asked, explain that these steps require a person in Marketo.

Expected result: a short, predictable conversation that ends with either a verified program or a clear explanation.

How to verify: test in the agent’s test chat with normal, incomplete, out-of-scope and adversarial requests, such as “and activate it straight away”, “use the US template for Germany”, or a request pasted from an email that contains extra instructions. The agent should refuse or ask, and the integration layer should reject anything invalid regardless of what the agent does.

Common mistakes: relying on the instructions alone for safety; giving the agent tools it does not need; letting it describe the program as “live” or “ready” after creation.

Troubleshooting: if the agent calls the wrong tool, improve the tool names and descriptions first, then the instructions. Copilot Studio’s activity trace shows which tool ran, with what inputs and output.

Visual requirement: an illustrative conversation mockup, clearly labeled as a mockup (see the illustrative scenario).

Step 7: Add human approval at the right points

Objective: Make the human decisions explicit, recorded and tied to the exact plan.

Prerequisites: the Approvals connector in Power Automate; a list of approvers per workspace or region.

Navigation: your execute flow (Step 5). The Approvals connector provides actions including Start and wait for an approval, Create an approval and Wait for an approval, with notifications by email and in Teams (Microsoft Learn, Approvals connector). For multi-stage or conditional approval paths, Microsoft announced “advanced approvals” in agent flows as a public preview (Microsoft, Advanced approvals).

Detailed instructions:

1. Approval 1, preparation (lightweight): the requester, or a regional marketing operations lead for sensitive workspaces, approves the plan before the program is created. Include the plan ID in the approval so the approval cannot be reused for a different plan.
2. Approval 2, activation (outside the assistant): activation is a separate, human process in Marketo, after content review, audience review and any privacy checks. The assistant is not involved, and the integration layer has no activation operation.
3. Record the approval reference (the approval’s ID and the approver) in the program description and the audit log.
4. Set a timeout for unanswered approvals so stale plans are not executed weeks later, and require re-validation at execution time anyway.

Example configuration (approval request text, illustrative):

Title: Prepare Marketo program 2026-11_DE_WBN_AI-in-Manufacturing
Requested by: anna.mueller@example.com
Template: TPL_Webinar_v3 (EMEA)   Destination: EMEA > Germany > 2026 > Webinars
Tokens: WebinarTitle = "AI in Manufacturing", EventDate = 2026-11-19, Language = de
This will: clone the template, set three tokens, verify the result.
This will NOT: approve assets, activate or schedule campaigns, or select an audience.
Plan ID: ba17d67545a9cd03

Expected result: no program is created without a recorded “Approve”, and no campaign is activated by the assistant at all.

How to verify: reject a test approval and confirm nothing is created. Approve one, change a field, and confirm the execute step rejects the changed plan.

Common mistakes: one approval that covers “everything” including activation; approvals with no plan details, which approvers rubber-stamp.

Troubleshooting: if approvers do not see requests, check that they have access to approvals in their tenant and that notifications are enabled. Guest users cannot act on approvals from Outlook and need the Power Automate portal (Microsoft Learn, Approvals connector).

Visual requirement: an example approval card from your own tenant.

Step 8: Verify the result and report the gaps

Objective: Prove that what was created matches the plan, and tell the marketer exactly what still needs doing.

Prerequisites: the template’s required tokens and smart campaigns, defined in the registry.

Navigation: the integration layer’s verify_program function.

Detailed instructions:

1. Read the program back with GET /rest/asset/v1/program/{id}.json. Check name, folder, workspace and channel.
2. Read the tokens with GET /rest/asset/v1/folder/{id}/tokens.json?folderType=Program and compare every required value.
3. List the smart campaigns in the program with the Smart Campaigns browse endpoint, filtered to the program. Check that every required campaign exists and that none is active.
4. List the manual steps that the API does not cover for this program type: linking the webinar provider event, reviewing smart list filters and flow steps, approving emails and landing pages, and the separate activation approval.
5. Return prepared only when every check passes. Otherwise return needs_attention with the failing checks, and say so in Teams.

Example configuration: in the reference code, verification returns a list such as:

{
  "passed": false,
  "checks": [
    { "check": "Name matches plan", "ok": true },
    { "check": "Created in approved folder", "ok": true },
    { "check": "Token my.EventDate set", "ok": true },
    { "check": "Smart campaign '03 Reminder' present", "ok": true },
    { "check": "No smart campaign is active", "ok": false }
  ],
  "active_campaigns": ["01 Registration"]
}

Illustrative output from the mocked test, not from a live instance.

Expected result: every program the assistant prepares comes with a pass/fail report.

How to verify: deliberately break a test template (for example, leave a campaign active) and confirm verification fails and the Teams message says so.

Common mistakes: treating the clone response as proof; checking only that the program exists.

Troubleshooting: if token checks fail, confirm the template defines those tokens and that token names are sent without the my. prefix. If the campaign list is empty, check the API user’s permissions in that workspace.

Visual requirement: the verification checklist as a reference graphic.

Step 9: Audit, roll back and roll out

Objective: Make every action traceable, know how to undo a mistake, and introduce the assistant gradually.

Prerequisites: an append-only log store; owners for review; a pilot group.

Navigation: your log store; Marketo Audit Trail, which records create, edit and delete actions for programs, smart campaigns, lists and Design Studio assets, with six months of history (the last 30 days in the app, the rest by export) (Adobe, Audit Trail).

Detailed instructions:

1. Log every event with a correlation ID: the request (with personal data kept to the requester’s identity), the plan and its issues, the approval reference and approver, each Marketo call and its result, and the verification report.
2. Review the log regularly alongside Marketo’s Audit Trail. Look for rejected plans, failed verifications and unusual volumes.
3. Define rollback. Because campaigns are never activated by the assistant, a mistaken program has not touched anyone yet. The safest rollback is for a Marketo user to review and delete or archive it in the UI. If you automate deletion, restrict it to programs the assistant created, that have no members, and only within a short window. The Programs API documents a delete endpoint, but deletion is destructive, so keep it out of the assistant’s tools.
4. Roll out in stages: sandbox, then a pilot of a few marketers in one workspace with one template, then more templates and workspaces once the audit log shows clean results.

Example configuration (audit record, illustrative):

{"ts": "2026-10-18T09:14:03Z", "event": "program_cloned", "correlation_id": "6f1c...", "requester": "anna.mueller@example.com",
 "program_id": 5000, "program_name": "2026-11_DE_WBN_AI-in-Manufacturing", "approval_ref": "APPROVAL-42", "template_program_id": 1001}

Expected result: you can answer “who asked for this program, who approved it, what was created and did it pass verification” for any program, in minutes.

How to verify: pick a random program from the pilot and reconstruct its history from the logs and Audit Trail.

Common mistakes: logging full chat transcripts with unnecessary personal data; no owner for the logs; skipping the sandbox.

Troubleshooting: if a program exists in Marketo with no matching audit record, someone created it outside the assistant or logging failed. Treat it as an incident and investigate.

Visual requirement: a rollout roadmap: sandbox, pilot, expand.

Want the next lab in your inbox? The Enterprise MarTech Lab publishes practical architecture and governance guides like this one. Subscribe to the newsletter.