Migrating from DataPress
How the concepts of AlexaCRM DataPress (WordPress.org slug integration-cds) and its legacy predecessor, the Dynamics 365 Integration plugin (integration-dynamics), map onto WBS Connect for Dataverse, a walkthrough of a real migration, and an honest list of what has no equivalent yet.
Concept mapping
| DataPress / legacy plugin | WBS Connect | Notes |
|---|---|---|
| Twig view or template listing records | Collection | Configured on the Collections tab: table, columns, status filter, search, filters, sort, paging. No template language; markup lives in PHP templates you can override. |
| Custom form (Twig or form builder) | Typed form | Ordered field list with types, validated on the server; create or update mode; Turnstile; success message and redirect. |
| Table binding of a page to a record | Slug detail page | The same page renders the grid and, with ?dvc=<slug>, one record. A slug column gives readable URLs; GUIDs keep working. |
| User binding (WordPress user to contact) | Business tier | Specified with email, column and custom binding modes; in development, see Pro and Business. |
| Twig access to Image and File columns | Image column and File columns | Served through a REST route on your site with a status-filter check; no direct Dataverse URLs on the page. |
| Cache panel with flush by type | Per-collection cache lifetime | Plus a site-wide default and a Flush cache button. |
| Webhooks management | Webhooks tab | form.created, health.failure, health.recovery; signed with an HMAC; Test link. |
| Monaco Twig block in the block editor | Three blocks with dropdowns | Collection, Record and Form blocks pick configured items; no code in the editor. |
| Form builder integrations | Pro: Contact Form 7 and Gravity Forms; free: the WBS Forms bridge | Mapped per form, typed like the built-in forms. |
| Registration and activation server (Premium) | Offline license token | No phone-home; the token is verified with an embedded key. |
| DataPress solution imported into Dataverse | Nothing to import | The application user and role are the only Dataverse-side setup. |
Legacy [msdyncrm_twig] shortcodes | [wbsdvc_collection], [wbsdvc_record], [wbsdvc_form] | Or the matching blocks. |
Migration steps
- Inventory. List every page with a DataPress or legacy shortcode and note the table, the columns, the filters and whether it lists, shows one record or writes.
- Identity. Create a dedicated app registration and application user for WBS Connect with a least-privilege role. Do not reuse the DataPress credentials; a separate identity makes the switch reversible and the audit trail clean.
- Collections first. Recreate each listing as a collection and check the grid on a draft page. Add the slug column, search, filters and sort, then compare the record count with the old view.
- Forms. Rebuild each form as a typed form, or keep a form builder and map it (Pro: CF7 and Gravity Forms; free: the WBS Forms bridge). Test one submission per form and check the record in Dataverse, including choices and lookups.
- Swap the pages. Replace the old shortcodes with the new ones (or blocks), keeping the page slugs so links and rankings survive. Set 301 redirects for detail URLs whose shape changes.
- Switch off the old plugin. Deactivate it once nothing references it any more, and set the alert email so the new connection tells you when something breaks.
Walkthrough: kraftfahrer-jobs.com
Leopold Michel recruits professional drivers on kraftfahrer-jobs.com. The application forms on eight landing pages in German, English and Croatian were legacy Dynamics 365 Integration forms writing into a custom application table in Dynamics 365. One day they stopped working. The cause, found weeks later: the client secret of the legacy plugin's app registration had expired, and nothing had said so.
The migration, in the order it happened:
- A new app registration and application user, with a custom role granting Create and Append on the application table and Read and Append To on the job table the applications refer to. One column was field-secured; a field security profile gave the application user access to it. Credentials went into
wp-config.phpas constants. - One WBS Forms form per language, rebuilt from the live forms at parity (the old forms never stored uploads, so none were added). Each form's messages localized.
- One bridge map per form slug, declared in a small must-use plugin with the
wbs_dataverse_connect_bridge_mapsfilter: strings for names and address lines, email, a date for the birthday, choices for salutation and referral with label-to-value maps generated from the table metadata (the German and English forms use different choice columns), multi-select choices for licenses and truck experience, a yes/no for the privacy consent, a lookup for the job resolved by name, and two fixed defaults. - Each landing page's legacy shortcode replaced with
[wbs-form slug="job-application"], the previous content kept in a backup field. Landing pages that advertise one job preselect it through a shortcode attribute. - Three real submissions, one per language, checked in Dataverse column by column, then deleted. The legacy plugin deactivated.
What changed for the client: applications land in Dataverse as typed records, a Dataverse workflow creates the contact and notifies recruiting, and the connection is probed twice a day. An expired secret now produces an email within hours instead of a support case weeks later. Forms keep accepting applications even if Dataverse is briefly unavailable; the failure is logged and alerted and the form's own mail still goes out.
What has no equivalent yet
- FetchXML. Collections build OData queries from configuration; there is no way to paste a FetchXML query. Filters are limited to search, typed column filters and a status filter.
- Saved views. Columns and filters are configured per collection, not read from Dataverse views.
- Ninja Forms. Supported builders are Contact Form 7, Gravity Forms and WBS Forms.
- Twig templates. Markup is customized through PHP templates in the theme instead.
- User binding, own-records views and conditional access. Business tier, in development.
- Elementor widget. Use the Shortcode widget.
- Model-driven form rendering with lookup dialogs. Lookups render as a select of up to 200 names.
If one of these blocks your migration, talk to us; most gaps have a configuration answer, and the roadmap is driven by real migrations.