AFI
General Settings
AFI → Settings → General holds the options that apply to the whole plugin rather than to one integration. Nothing here is required to get a first integration working, but several of these settings decide how much you can see when something goes wrong, so they are worth a pass early.
Click Save Changes at the bottom to apply anything you change. A Reset to defaults button sits alongside it and clears the six options below back to their shipped state. It deliberately leaves your platform activation list alone, because that list usually represents real setup effort.
Logging
Disable Logging
Off by default, which means logging is on. Every request AFI sends is recorded in AFI → Log along with the outgoing payload, the HTTP status, and the platform’s response body.
Turning logging off stops new rows being written. Existing rows stay where they are. Only switch it off if you have a specific reason, such as a very high submission volume on a small database, because without a log you are troubleshooting blind: a failed integration leaves no trace at all.
If your concern is personal data rather than volume, you do not have to lose the log entirely. The adfoin_log_request_args and adfoin_log_response_body filters let you redact fields before they are stored. See Hooks and Filters.
Log Retention
A number of days. Rows older than that are deleted automatically by a daily background job.
Set it to 0 to keep logs forever, which is the default. Any value above zero schedules the cleanup job; setting it back to zero unschedules it. The cleanup is a plain delete on the log table, so on a busy site pick a window you can live with rather than the largest number you can imagine: 30 or 90 days suits most sites.
The schedule is reconciled every time you save, so if the recurring job is ever cleared by something else, hitting Save Changes again puts it back.
Send Error Email
Off by default. Switch it on and AFI emails your site administration address whenever an integration fails.
A failure means either a transport error, so the request never reached the platform, or any HTTP status outside the 200 range. That covers the cases you actually care about: 401 for bad credentials, 422 for a rejected payload, 429 for rate limiting, and 5xx for a platform outage.
The email names the integration and its ID, the platform, the form, the status code and message, and links straight to the log entry.
Notifications are throttled to at most one per hour for each combination of integration and status code. One expired API key firing on every submission produces one email an hour, not one per visitor.
Next to the toggle is a Send test email button. It sends a sample immediately so you can confirm your site’s mail configuration works before you rely on the real thing. If the test fails, the problem is WordPress email delivery rather than AFI; an SMTP plugin is the usual fix.
Developers can redirect these notifications to Slack, an error tracker, or a shared inbox with the adfoin_send_api_error_email action and the adfoin_error_email_to, adfoin_error_email_subject, and adfoin_error_email_message filters.
Disable Special Tags
Off by default, which means special tags are available. Special tags add submission timestamps, visitor details, site information, page context, and logged-in user details to every field-mapping dropdown.
Switching this on removes the whole group from the mapping UI. Integrations you already saved keep working, since the setting only controls what the dropdown offers.
Enable UTM Tracking
Off by default. Switch it on to start capturing campaign parameters and advertising click IDs, and to make the UTM group appear in your mapping dropdowns.
Capture is first-touch and lasts 30 days. The full list of parameters and the details of how capture behaves are in UTM Parameters and Special Tags.
Enable Job Queue
Off by default. This decides whether integrations run inside the form submission request or in the background through Action Scheduler.
With the queue off, each integration fires while the visitor waits. A slow platform makes your form feel slow, and several integrations on one form add up.
With the queue on, the submission is handed to Action Scheduler and the visitor gets their confirmation immediately. This is the better choice on almost every site, and it becomes important once a form has more than one or two destinations.
There is one thing to know about ordering: background jobs run within roughly a minute on a healthy site, but they depend on WordPress cron. If your site has cron disabled or a broken system cron, queued jobs sit unprocessed.
AFI has two safety nets so a submission is never silently lost. If Action Scheduler rejects the job, which can happen when a very large payload such as a full WooCommerce order exceeds its argument size limit, the integration falls back to running synchronously. The same fallback applies when a platform has no queue listener registered.
Queue health
Underneath the toggle is a small card showing pending jobs, failed jobs, and when a queued job last completed. It only counts AFI’s own dispatch jobs, not everything else on your site using Action Scheduler.
A pending count that keeps climbing while the last run time gets older is the signature of a stalled cron. A growing failed count points at the platform side instead, so check AFI → Log for the responses. The card is hidden when Action Scheduler is not available.
Platform activation
Below the toggles is the list of every destination platform AFI supports, each with a checkbox.
Only the platforms you tick appear when you build an integration. With more than three hundred receivers registered, leaving them all on makes the action dropdown unwieldy, so ticking the handful you actually use is the point of this list.
Unticking a platform does not delete its saved credentials or break integrations that already use it. It only hides it from the picker.
This list is not touched by Reset to defaults.