Manage Data Security Policies
Purpose
Provide a controlled, cross-pillar method to export, validate, and approval-gate the import of the Manage Data Security Policies FSM setup task. Delegate transport and live import execution to the declared shared and core dependencies. Capture the user's policy design and prepare supported FSM changes.
Export and move the FSM setup task Manage Data Security Policies only through
the declared dependency workflows. Its catalog identity is
ASXS_MANAGE_DATA_SECURITY_POLICIES; require a current catalog or live-task
lookup to confirm that export/import remains supported before execution.
Scope and boundaries
- Support task-level FSM CSV export and subsequent import of either the exact exported archive, a verified-template candidate or a user-supplied modified copy.
- Accept policy creation, updates, deletion and redesign, including supported policy grants and conditions. Preserve user-specified scope and use only this task's verified contract. Route role-definition changes to Manage Job Roles or Manage Duties rather than substituting their archives here.
- Do not call Fusion, OAuth, UCM, REST, FSM, or loader commands directly.
shared.setup-export.task-level-exportowns export;core.data-loaderowns import preflight, upload, initiation, and monitoring. - A modified archive is a fresh source: calculate a new SHA-256 and repeat validation, preview, and immediate-approval gates. An approval for the original export does not approve a modified archive.
Required preflight
- Resolve the project workspace, requested operation, source and target environments, and exact policy scope. For migration, source and target must differ; for a same-environment restore, require explicit confirmation.
- Confirm task name and code with
shared.setup-export.task-level-exportand verifyCSVExportImportSupportedFlagisY. On an ambiguous, unavailable, or unsupported task, record a catalog-mismatch diagnostic and stop. - Confirm Functional Setup Manager export access in source and Data Loader import privileges in target. Never request or expose credentials or tokens.
- Persist redacted source/target, task-code, scope, and execution-plan details before side effects.
Export
- Route export to
shared.setup-export.task-level-exportwith task nameManage Data Security Policies, task codeASXS_MANAGE_DATA_SECURITY_POLICIES, source environment, and project ID. - Let that skill complete discovery, support validation, process creation, polling, download, and project export persistence. Never substitute a template export for a data export.
- Preserve the returned ZIP unchanged and register its path, SHA-256, process ID, task identity, source environment, and timestamp. Preserve timeout or failure diagnostics; do not automatically start another export.
Create, update, delete and redesign
Accept these operation requests for this task's own setup objects, including
user-specified individual changes. Prepare supported changes using the target's
FSM template and execute them through core.data-loader; do not reject a
request merely because the user does not already have an input archive.
Read FSM input preparation when preparing a change or helping a user understand the input. Obtain and safely extract the template, explain its files and required columns, map supplied business values, and prepare a separate candidate. Automatically authorize only the necessary template/spec export; retain Data Loader's validation and actual import approval workflow.
For deletion, verify the explicit supported action for the exact object or relationship. An omitted CSV row, blank value or unrelated REMOVE action is not whole-object deletion. If the task has no supported deletion contract, record that specific operation gap; do not impose a blanket prohibition on all individual changes or invent a browser/API execution route.
For update or redesign, establish existing keys, preserve unrelated values and show the intended changes. Intentional changes in the selected target are not same-environment restores. Apply restore confirmation only to an actual restore.
Template-first import preparation
- Unless the user explicitly overrides this sequence, export the task first and provide that export as the import template before asking for import content. Explain that the template establishes the supported archive and file structure; it is not approval to import.
- When the user provides an input file, compare it with the export template for file names, headers, column order, encoding, required values, and task-specific references. Help correct structural defects in a separate candidate file; preserve the supplied original and do not silently alter business values.
- Give the user a concise change summary and identify any unresolved values or references. Use the corrected file only after it conforms to the export structure and has been assembled into a new candidate archive using the supported archive shape. That candidate is a new artifact and must pass the validation and approval gates below.
- The user may override the export-first sequence, template choice, or proposed file corrections at any time. Honor that direction, while retaining the required task-identity, validation, and immediate import-approval gates.
Validate and import
- Require a non-empty ZIP and bind its SHA-256 to the task code, source, and
target. Route archive validation to
shared.validation.setup-data-validator. Fail closed on archive-shape, task-identity, scope, catalog, environment, or privilege mismatch. - The ZIP must remain unchanged after validation. Do not unpack, repack, merge, or transform it. A user-modified copy begins a new validation cycle.
- Route only the immutable validated archive to
core.data-loaderas an FSM, task-routed import, with target environment, task context, SHA-256, and validation evidence. - Let Data Loader complete source/API validation and create an immutable approval preview. Do not replace that route with direct FSM, UCM, REST, CSV, or browser operations.
- Present the exact target, task code, archive name and SHA-256, validation result, and expected policy impact. Stop before the first POST. Proceed only after a separate, immediate approval for that unchanged preview.
- Data Loader owns upload, initiation, monitoring, and diagnostics. Do not retry uploads, imports, overwrite/replacement operations, or failed jobs without fresh approval.
Failure handling
Classify failures as input validation, catalog mismatch, authorization, transport/environment, Fusion API, process timeout, process failed, artifact persistence, or approval blocker. Redact credentials, tokens, customer data, and sensitive policy details. Persist a redacted blocker and next action, then stop on ambiguity or unsafe paths.
Golden scenarios
| Scenario | Expected result |
|---|---|
| Export policy setup | Confirm identity and route only to task-level export. |
| Import the unmodified export | Require ZIP hash, shared/core evidence, and separate immediate approval before Data Loader handoff. |
| Import a modified exported file | Treat it as a new archive and repeat validation and approval gates. |
| Request direct FSM/UCM/REST/browser import | Stop; catalog flags do not authorize a replacement route. |


