SocialMediaExec Migration

Overview

SocialMediaExecModule is a retired compatibility module. Version 2.0 is hidden from Workflow Studio and never authenticates a social adapter, publishes content, or reads a provider timeline.

The former implementation had no workflow inputs or outputs. Calling it directly authenticated an injected adapter, published the hard-coded text Hello from our refactored SocialMediaExecModule!, fetched five timeline posts, logged provider data, and swallowed failures. Version 2.0 removes those unexpected side effects. The class remains loadable so saved workflows can be inspected and migrated, but every execution fails closed with MODULE_RETIRED.

Usage

Do not add SocialMediaExecModule to a new workflow. For each saved task that references it:

1. Identify whether the workflow intended to publish or read provider data.
2. Choose a dedicated provider module for the required operation.
3. Bind a least-privilege IntegrationAccount to the replacement module.
4. Map explicit content, media, identity, and operation inputs instead of relying on adapter defaults.
5. Review the replacement's validation, approval, idempotency, and ambiguous-write rules.
6. Test with an authorized sandbox or non-production provider account before replacing a production task.

Inputs

The compatibility shell recognizes three migration hints. It does not parse or transmit them.

Name	Type	Required	Version 2.0 behavior
platform	string	No	Ignored. No adapter is selected or authenticated.
content	string	No	Ignored. No content is published or logged.
operation	string	No	Ignored. No create, list, or timeline operation runs.

Outputs

Name	Type	Description
status	string	Always error.
error.code	string	Always MODULE_RETIRED.
error.message	string	Safe migration guidance.
error.retryable	boolean	Always false; repeating the task cannot call a provider.
error.migrationTargets	array	Dedicated provider module class names to evaluate.

No post URI, provider identifier, permalink, timeline data, publication timestamp, or success status is produced.

IntegrationAccount Requirements

SocialMediaExecModule accepts, loads, and decrypts no credentials. There is no account configuration that re-enables its former adapter path.

Create an IntegrationAccount only after choosing a dedicated replacement. Keep provider access tokens and account identifiers in the replacement module's documented encrypted fields, require the account's expected readiness state, and grant only the scopes needed for the selected operation.

Configuration

Direct metadata lookup exposes two advanced legacy hints so old configurations can be recognized:

Field	Legacy purpose	Version 2.0 behavior
platform	Selected a social adapter.	Never resolved.
operation	Requested a provider create or read.	Never invoked.

The module is discoverable=false; Workflow Studio does not offer it for new tasks.

Operations

Version 2.0 implements one deterministic compatibility operation: reject execution and return supported migration targets.

Replacement	Intended provider behavior
XPostModule	Create a text, reply, quote, or pre-uploaded-media X Post.
FacebookPagePostModule	Create an immediate, draft, scheduled, link, or remote-photo Facebook Page post.
LinkedInCompanyShareModule	Publish an authorized LinkedIn organization Post.
InstagramPublishModule	Publish supported Instagram Business media.

For a legacy read or timeline workflow, use a separately reviewed provider-specific read module. Do not substitute a publishing module for a read operation.

See the Social Media ExecModules guide for current provider paths. The older SocialPostModule migration guide covers the other retired generic publisher.

Errors and Failure Modes

Failure	Meaning	Recovery
MODULE_RETIRED	The workflow still references the generic adapter module. No provider authentication, publish, or read occurred.	Replace the task with a reviewed provider-specific module.
Replacement validation error	Required content, media, identity, or account fields are invalid.	Correct the named replacement input; no request should be sent before validation passes.
Replacement ambiguous write	A timeout, rate limit, or provider error leaves commit state unknown.	Inspect provider state before a deliberate retry; do not assume the write failed.

The compatibility response never includes legacy content, credentials, adapter output, provider response data, or exception text.

Example

Legacy migration hints:

{
  "platform": "x",
  "operation": "create_post",
  "content": "Release notes are live"
}

Expected result:

{
  "status": "error",
  "error": {
    "code": "MODULE_RETIRED",
    "message": "SocialMediaExecModule is retired; replace it with a dedicated provider ExecModule",
    "retryable": false,
    "migrationTargets": [
      "XPostModule",
      "FacebookPagePostModule",
      "LinkedInCompanyShareModule",
      "InstagramPublishModule"
    ]
  }
}

For this example, migrate to XPostModule, bind a READY X IntegrationAccount, map content to text, and follow the X module's non-idempotent retry policy.

Notes

• Pagination: not applicable; the compatibility shell performs no timeline or list read.
• Limits: legacy hints are not parsed, rendered, stored, or transmitted.
• Idempotency: repeated execution returns the same failure shape and has no external side effect.
• API constraints: no provider API is called. Provider-specific constraints apply only after migration.
• Destructive behavior: none. The compatibility shell cannot publish, update, delete, authenticate, or read posts.
• Observability: one bounded warning records that execution was blocked; legacy input and credentials are not logged.
• Runtime boundary: source metadata changes appear in the deployed Workflow Studio catalog only after a separate ValkyrAI runtime deployment. Until then, the live /v1/modules/metadata response remains authoritative.