Enable Tables Offline

Shared instructions: shared-instructions.md — read first.

References:

• offline-profile-schema.md — entity field map (IsAvailableOffline, ChangeTrackingEnabled)

Enable Tables Offline

Flip IsAvailableOffline=true AND ChangeTrackingEnabled=true on the EntityMetadata of one or more Dataverse tables, then publish customizations. This is the prerequisite shown in Image 4 of the maker portal ("Can be taken offline" + "Track changes") — without both, a table CANNOT be added to a Mobile Offline Profile.

Sequential (Dataverse metadata lock) and idempotent: re-running on an already-enabled table is a no-op.

Workflow

1. Verify project & auth → 2. Resolve table list → 3. Inspect current state → Gate → 4. PUT EntityMetadata per table → 5. Publish → 6. Verify → 7. Summary

Step 1 — Verify project & auth

test -f power.config.json && test -f app.config.js
node "${PLUGIN_ROOT}/scripts/resolve-environment.js" "$(node -e \"console.log(require('./power.config.json').environmentId)\")"

Capture the Environment URL from the resolver for <envUrl>. STOP if not authenticated.

Step 2 — Resolve table list

Tables to enable come from one of (in order):

If the resolved list is empty, STOP with: "No Dataverse tables found in this project. Run /add-dataverse first."

Step 3 — Inspect current state

Print before starting:

"→ Querying current IsAvailableOffline + ChangeTrackingEnabled for <N> table(s)…"

For each table, in sequence:

node "${PLUGIN_ROOT}/scripts/dataverse-request.js" <envUrl> GET \
  "EntityDefinitions(LogicalName='<table>')?\$select=LogicalName,DisplayName,IsAvailableOffline,ChangeTrackingEnabled,IsCustomizable"

Build a status table:

| Table              | IsAvailableOffline | ChangeTrackingEnabled | IsCustomizable | Needs change? |
|--------------------|--------------------|-----------------------|----------------|---------------|
| cr123_note         | false              | false                 | true           | YES (both)    |
| cr123_visit        | true               | false                 | true           | YES (track)   |
| contact            | true               | true                  | true           | NO            |

Hard rule: if IsCustomizable.Value=false on any table, that table CANNOT be modified. Drop it from the change set and flag in DONE_WITH_CONCERNS — system-managed tables (most OOB) require an admin solution patch path the skill does not handle.

Gate — Approval before mutation

Enter plan mode with the status table from Step 3 plus the planned operation per table. Wait for user ExitPlanMode before proceeding.

Plan body:

The following EntityMetadata changes will be PUT in sequence:

cr123_note   → set IsAvailableOffline=true, ChangeTrackingEnabled=true
cr123_visit  → set ChangeTrackingEnabled=true (IsAvailableOffline already true)

After all updates, a single PublishAllXml request will commit the changes.

Tables already in the desired state are skipped (no API call).

If the user rejects, STOP. If they approve, proceed.

Step 4 — PUT EntityMetadata per table

Print before starting:

"→ Updating EntityMetadata for <N> table(s) sequentially (Dataverse serializes metadata writes)…"

⚠️ Concurrency rule — do not violate. Metadata writes hold an exclusive lock per org. Issue one PUT, wait for 2xx, then the next. No batching, no parallel calls. Same rule as /add-dataverse Step 5.

For each table needing change (skip ones already in target state):

node "${PLUGIN_ROOT}/scripts/update-entity-offline-flags.js" <envUrl> \
  --table <table> \
  --offline true \
  --tracking true

The helper:

• Re-reads EntityMetadata to pick up the current MetadataId + SchemaName (both required in the PUT body — Dataverse rejects PUT without them).
• Sends MSCRM.MergeLabels: true so display labels are preserved (the alternative wipes labels — never use false).
• Returns { "status": 200, "noop": true, ... } if the table is already in the target state (skip silently).
• Returns { "status": 200, "skipped": "uncustomizable", ... } for tables whose IsCustomizable.Value=false (system-managed; you must surface as DONE_WITH_CONCERNS).
• Returns { "status": 204, ... } on successful update.
• Handles 401 token refresh and 429 back-off automatically.

If the helper returns status 403 PrivilegeCheckFailed: the user lacks "Customize System" privilege. Print the table name and which privilege is missing, then STOP.

If status 400 with ChangeTrackingEnabled cannot be disabled: ignore — that path only triggers when going from true to false, which we never do.

Print ✓ <table> after each 204; print ↷ <table> (already enabled) for no-ops; print ⚠ <table> (uncustomizable) for skips.