A brief becomes a real page.Inspect bookings, courses and email plugins before editing
Read the installed plugin's capabilities, records and versions before planning a change.
Video coming soon
Your next step is ready.
Follow the complete written guide below.
The video will join it here when it’s ready.
Before you start
- EMCP Pro 3.19.0 with one of the supported plugins active on a practice site.
- A connected user with that plugin's own permissions; use synthetic contacts, students and bookings.
Let’s do this, step by step.
Step 01
Read setup and permissions
Use the installed integration's read tool and get-setup. Record its version, edition, available operations and acting user's permissions. FluentCRM also requires its own MCP switch for reads beyond setup. Keep write tools off for this lesson.
Start with the plugin that is actually installed. Read its setup instead of assuming every edition or user can perform the same operations. This lesson only reads existing records.
Step 02
Inspect one relevant record
For Amelia, read a service, employee working hours and availability in site-local time. For The Events Calendar, read an event with its time zone, venue and organizers. For Tutor LMS or LifterLMS, read a course's ordered curriculum. For FluentCRM or MailPoet, inspect a synthetic contact or subscriber and a draft email, including consent state and automation settings.
Read the details that affect a later change. A booking depends on working hours, an event on its time zone, a course on its curriculum, and an email on its audience and consent. Preserve the returned record versions.
Inspect the supported business plugin on this practice site. Read setup and one synthetic record, report its version and dependencies, and explain the checks needed before editing. Do not enable writes, send email, enroll students, publish, or create bookings.
Step 03
Review the proposed next action
Compare the returned record with the plugin's native admin screen. Identify the exact object, fields, permissions and version a later write would need. Treat sending, automation execution, enrolment and publishing as separate decisions. Follow the linked integration guide for its operation-specific dry-run, confirmation and recovery rules.
Verify the read in the native interface. A successful read does not approve a write or an external effect. Plan one specific next action and review its recovery limits before enabling the write tool.
You’re done when…
The native admin screen matches the read result, the record version is recorded, and no booking, enrolment, publication or email was created.
Keep the reference handy.
The docs cover tool details and requirements for this lesson.