Migrate from Paradym to Zoho CRM

Nested attribute flattening requires upfront schema mapping decisions

Paradym stores credential attributes as nested JSON objects (e.g., attributes.person.firstName, attributes.person.address.street) and nested arrays (nationalities list). Zoho CRM standard fields are flat key-value pairs. FlitStack must split every nested path into a separate Zoho custom field — there is no native JSON storage in Zoho CRM custom fields. If the Paradym schema includes dynamically named nested keys (e.g., the field name itself varies per credential type), the migration plan must include a flattening rule for each variant before any data moves. Skipping this step produces Zoho records with empty fields or JSON blobs that Zoho's UI cannot render.

Paradigm API rate limit of 200 requests per 10 seconds constrains extraction speed

Paradym enforces a global rate limit of 200 requests per 10 seconds per IP address across all services including the dashboard, agent, and docs portals. This is not configurable per desk. Large credential datasets (50,000+ records) require paginated API polling that, at this rate limit, extends extraction time significantly. FlitStack implements exponential backoff and request batching to stay within the 200-req/10s ceiling, but teams should plan extraction windows accordingly. Zoho's Bulk Write API on the destination side (Enterprise tier: 10,000 API credits/min) can receive data faster than Paradym can extract it, so the migration bottleneck is almost always on the Paradym source side.

Paradym blocked regions prevent API extraction from certain geographic origins

Paradym blocks API requests from China, Russia, and North Korea at the network layer. If the migration is being executed from an IP address in any of these regions, the Paradym API will return a 403 Forbidden response and no data can be extracted. Teams must ensure their extraction infrastructure runs from an unblocked region (e.g., a Zoho-compatible data center in the US, EU, or Singapore). This is not a Zoho-side issue — it is a Paradym network security policy that applies to all API operations including credential exports.

Credential templates and disclosure templates become orphaned reference data without manual linking

FlitStack migrates Paradym credential templates and disclosure templates as records in Zoho CRM Custom Modules, but Zoho CRM does not enforce referential integrity between custom modules the way a relational database does. After migration, the Credentials_C records that link to Credential_Templates_C via a Lookup field will display correctly if the Lookup resolves, but Zoho does not cascade-delete templates if a credential is deleted. Teams should review the integrity of the Credential-to-Template lookups as part of post-migration validation and configure Zoho validation rules or Blueprint conditions if template assignment should be enforced.

Credential status history requires a custom audit module since Zoho does not track field-level history on custom modules by default

Paradym credentials carry a full status transition history (Issued → Presented → Revoked, with timestamps and actor IDs). Zoho CRM's built-in audit trail applies to standard module field changes, but custom modules in Zoho CRM do not have automatic field-history tracking on the Free and Standard tiers. FlitStack creates a Credential_Status_Log_C module to store every status transition as a separate record, but this requires the team to decide whether to display the log as a related list on the Credentials_C layout or as a separate module tab. Teams that need Zoho-native field history on custom modules must be on the Zoho CRM Enterprise or Ultimate tier with the Audit Logs feature enabled.