Apps Common Extensible Flexfields
Purpose
Manage EFF setup-data tasks routed from pillar setup-task skills without owning CSV transport. Read EFF setup-task guidance before acting.
Use shared.setup-export.task-level-export only for export and
core.data-loader only for approved FSM CSV import. For EFF metadata
deployment or deployment status, use only core.fusion-api.rest-api-client
as specified in the EFF reference.
EFF Deployment Workflow
Read the REST Deployment and Status section of EFF setup-task guidance. It is separate from CSV import: an EFF deployment compiles the already-configured flexfield; it does not transport setup data. After the Import EFF Setup Data workflow has completed successfully, enter this workflow for the imported EFF. Do not deploy after an incomplete or failed import.
- Preflight the confirmed target environment,
application_id, EFFflexfield_code, optionalforce_deploymentvalue ("true"or"false"), and the caller's required Fusion privilege. When the calling skill omits it, setforceDeploymentto the documented default,"false". Preserve URL encoding in the flexfield code (for example,%23); do not infer or substitute identifiers. - For a live deployment, present the exact target environment, POST endpoint,
and immutable JSON payload, then obtain explicit approval immediately before
invoking the REST client. Submit the request with
fusion_rest_client.py, which uses the default Fusionscopefor/fscmUI/applcoreApi. - Capture
jobId,jobStatus,deploymentStatus,validationStatus,validationReport,deploymentErrorMessage, and the response links. Do not retry a POST without explicit approval. - For status, call the documented
getDeploymentStateGET endpoint through the REST client using the same resolved identifiers. Poll only when asked, using the bounded interval and timeout in the reference; stop at a terminal response or timeout. - Run a caller-supplied
post_deployment_actiononly after status confirmsDEPLOYED. Follow the Task-Specific Post-Deployment Action section of the EFF reference. Do not infer, substitute, or run a post-deployment action for a task that does not explicitly define one.
Preflight and Error Handling
Resolve task identity from the calling pillar skill, verify
ExportImportSupportedFlag, and preflight the selected workflow's target,
artifact, and approval requirements. Classify an unsupported task as
catalog_or_metadata_mismatch and an unapproved import as
approval_blocker. Redact credentials, tokens, and sensitive setup data from
diagnostics.
For deployment, classify malformed identifiers or force values as
input_validation; a 401/403 after the REST client's one refresh attempt as
authorization_or_privilege; HTTP failures as fusion_api_error; and a
nonterminal result at the polling limit as process_timeout. Return the last
safe status and job ID to the calling project workflow; never persist OAuth
tokens, secrets, Authorization headers, or sensitive setup data.
For a caller-supplied post-deployment action, classify a missing successful
DEPLOYED status as process_failed, an unapproved POST as
approval_blocker, and an unsuccessful job result as process_failed.
Capture the response and any request identifier in post_deployment_result.
Do not retry the POST without a new explicit approval.


