Core Support

The Create Core Support ticket action turns each form submission into a ticket in Core Support, the help desk plugin, on the same WordPress site. Agents reply from Core Support, the customer gets those replies by email, and signed-in customers also see the ticket in their account.

The action is listed under Support & Tickets on a form’s Actions tab. It needs the Core Support plugin installed and active.

Add the action

1. Edit the form and open its Actions tab.
2. Under Support & Tickets, click Create Core Support ticket.
3. Map the fields described below.
4. Optionally check Run in the background.
5. Click Save Form.

Field mapping

Setting	Default	What it does
Customer email field	EMAIL	The form field that holds the customer’s email address. Required.
Customer name field	NAME	The form field that holds the customer’s name.
Ticket subject	[SUBJECT]	The ticket’s subject. Accepts data variables. If it comes out empty for a submission, Core Support uses “Message from” and the form name.
Ticket message	[MESSAGE]	The ticket’s first message. Accepts data variables and plain text. Required.
New tickets	Open a ticket straight away	Choose Hold in Incoming mail for review to have an agent approve each request before it becomes a ticket.

The two field settings are dropdowns of the form’s own fields. If a saved mapping points at a field the form no longer has, the dropdown shows Missing field: followed by the old name, so you can pick a new one. At submission time, a mapped email field that isn’t in the submission fails the action with a clear error instead of creating a ticket without a customer.

Build the ticket message from as many fields as you need:

[DESCRIPTION]

Site URL: [SITE_URL]
Category: [CATEGORY]
Priority: [PRIORITY]

One ticket per submission

Each submission creates exactly one ticket per action. The action passes Core Support a reference built from the form, the entry and the action, and that reference stays the same on every retry, so a retry doesn’t open a second ticket.

The action log records the outcome:

• Core Support ticket #123 created. The log entry includes a link to the ticket in the admin.
• Sent to Core Support. It appears in Incoming mail, then as a ticket. This appears when New tickets is set to hold requests for review.

Background queue and retries

Check Run in the background to create the ticket from the background queue instead of during the visitor’s request. The visitor sees the success message straight away, and a failed attempt is retried with backoff.

• The queue uses the saved entry, so the form must save submissions. If submission storage is off, the action runs immediately instead.
• Without the checkbox, the action runs during the submission. If it fails with a temporary error and the entry is saved, Core Forms still moves it to the queue and retries it a couple of minutes later.

See Async Action Processing and Action Retries and Logs for how the queue, retries and logs work.

Test the action

Administrators see a Test action panel inside the action’s settings. It’s prefilled with sample values for the form’s fields as JSON. Edit them, then click Send test request.

The test sends a real request, so it creates a real ticket. Use your own email address and test data.

Support request template

The Support request template is set up for Core Support. When you create a form from it while Core Support is active, it gets three actions:

1. An admin notification email. Its closing note says the request is also a ticket in Core Support, and replies to it go straight to the customer.
2. A Create Core Support ticket action that runs in the background. It maps EMAIL and NAME, uses [SUBJECT] as the subject, and builds the message from the description, site URL, category and priority.
3. A confirmation email to the customer with a copy of their request.

The template checks for Core Support when the form is created. If you activate Core Support later, add the ticket action to existing forms yourself.

The industry intake templates never add a ticket action. They send an admin notification and a confirmation email whether or not Core Support is active.

Confirmation emails with Core Support active

Core Support emails the customer only when an agent replies. It doesn’t send an acknowledgement when the ticket is created. That’s why the Support request template keeps its own confirmation email even with Core Support active, so the customer always hears back right away.

If you add the ticket action to another form, add an autoresponder too if you want the customer to get an instant confirmation.

When Core Support isn’t active

Without Core Support, the Create Core Support ticket button stays visible but disabled. Hover over it to see why: “Core Support is not active or a supported version is not installed. Install and activate it to use this action.”

The Support request template still works. It sends the admin notification and the customer confirmation, and the notification tells you to reply to the email to answer the customer.

For developers: queueable actions

Only action types on an allowlist can run from the background queue. Core Support’s core_support type is already on it. A companion plugin can add its own action type with the cf_queueable_action_types filter:

add_filter( 'cf_queueable_action_types', function ( array $types ) {
    $types[] = 'my_ticket_action';
    return $types;
} );

Add a type only when its handler is safe to run twice with the same execution key (it must not create a second record on retry) and doesn’t need the visitor’s request, such as a redirect. Queueable types get the Run in the background checkbox in their settings.

Related

• Actions Overview
• Autoresponder
• Fluent Support
• Templates