Turning submissions into articles — a call for submissions, a press-release inbox, a community bulletin

A form can feed the Articles module as well as your inbox and your CRM. Use it for a call for submissions, a press-release inbox, a member newsletter, a neighborhood bulletin — anywhere people outside your organization write something you might publish.

Turning it on:
1. Open the form and find the Articles box in the settings column.
2. Switch on "Also create an article from each submission".
3. Pick the article type the submissions should be filed under. The list is your own article types from the Articles module; if you have none yet, add them in Articles and come back — until then, submitted articles file with no type.

Mapping questions to article fields:
Article routing uses the same "Where does this answer land?" dropdown every other question uses. Once the toggle is on, these targets appear in it:
• Article title — the headline. One question.
• Article summary — the short description shown in article lists.
• Article body — the main text. Map several questions here and they become paragraphs, in the order they appear on the form.
• Article cover image — a Photo question. The image goes through Turtini's image-moderation check on upload. Once it is approved, Turtini copies it into the article's own image storage and uses that copy as the cover; the submitted file stays private where it was uploaded, so publishing a cover never opens up the rest of what people send you. A photo still awaiting review is NOT copied — the article arrives with no cover and the submission review screen tells you why. You do not have to do anything about that: the moment the photo clears review the cover attaches itself. If a photo is later rejected, the public cover is deleted and the article's cover is cleared in the same step, so an article never shows a broken image; approving it again puts the cover back.
• Article tags — a Pick-many, Pick-one or short-text question. Commas separate tags.
• Article button link — a Link question. The answer becomes a button at the end of the published article.
• Article button label — the text on that button.
• Event ticketing link — a Link question, for a form that collects where people buy tickets. Same button, different default wording.
• Ticket button label — the text on the ticket button.

Turning a link into a button:
Give the question the Link answer type, then map it to "Article button link". A question like "For More Information" with the placeholder "Share a link if your readers can access another site for more information" becomes a real button on the published story.

Why Link and not Short text: a short-text question accepts anything, and a link that ends up as a button on a page you publish is a place where a wrong value is visible to your readers. The Link type checks the answer before it is stored, and it is the only type the button targets accept.
• Someone can type outlife757.com — no "https://" needed. It is saved as https://outlife757.com.
• Web addresses only. Email addresses, phone links, and anything that is not a normal http or https address are refused, with a message telling the person what to fix while they are still looking at the form.
• A refused link means the article gets no button. It never gets a broken one, and the rest of the story still arrives.

What the button says, in order:
1. an answer mapped to "Article button label", if the form collects one;
2. otherwise the link question's own wording — "For More Information" reads well as a button, which is why it is the fallback;
3. otherwise "More information". A ticketing link falls back to "Get tickets" instead.

Buttons render on every kind of article — a news story, not only an event. An article can carry both buttons at once (a ticket link and a details link); they appear side by side, tickets first. You can edit or remove either one in the Articles editor before you publish.

If the form collects EVENTS, most of the article fills itself:
A question can land in only one place. On a form that creates real events, the Event Name question is mapped to the event, the Organizer Name question is mapped to your CRM, and so on — which used to mean the article those same submissions produced arrived almost empty, because none of those answers could also be pointed at an article field.

Now, when the article type you picked in step 3 is named "Event" or "Events", those answers fill the matching article fields as well. Nothing to configure and nothing to remap:
• Event name becomes the article headline.
• Event description becomes the article body.
• Event date becomes the article's event date. An event time question, if you have one, sets the start time; without one the date is listed as all-day.
• Event location becomes the article's address, which is what draws the map on the article page.
• Organizer name, contact email and contact phone become the article's organizer, organizer email and organizer phone.
• A question whose wording mentions tickets, registration or RSVP becomes the ticket button, as long as the answer is a usable web address.

Two rules worth knowing:
• Anything you mapped yourself wins. If you pointed a question at "Article title", that answer is the headline and the event name is not. This only fills fields that would otherwise be blank.
• A date it cannot read with certainty is left blank, on purpose. "Next Saturday", "October 4" with no year, and "03/04/2026" (which is October 4th to some readers and April 3rd to others) are all refused rather than guessed, because a wrong date on an event listing sends people to a venue on the wrong day. The submission review screen tells you exactly which answer it could not read, and you type the date in the Articles editor. Dates picked from the form's date question are always read correctly.

Venue name is the one field that stays blank. The form asks for the location as a single answer, and splitting "333 Waterside Drive, Norfolk" into a venue and a street would be a guess. Add the venue name in the Articles editor if you want the map pin labeled.

None of this touches a form filed under any other type. A News article is exactly what it always was.

What happens to questions you do not map:
Nothing reaches the article from them. That is deliberate — an intake form usually collects a name, an email and a phone number alongside the story, and those do not belong in a published article. Those answers are not lost: they stay on the submission, and the form editor lists them under "What the article gets" so you can see exactly what will and will not travel, before the first submission arrives. The submission review screen names them again afterwards.

Where the article lands, and why it can never publish itself:
Always in the Pending Review tab of Articles, visible only inside your organization, with no publish date. A published intake form is open to anyone with the link, so a stranger can create one of these — which is safe only because nobody outside your organization can see it until a member of your team opens it, edits it if they want, sets it public, and publishes it. There is no setting anywhere that changes this, on purpose.

Routing is an addition, never a replacement:
The submission still lands in your review inbox and still populates Contacts, Accounts and every other target you mapped, exactly as it does with this switch off. If the article cannot be created — the Articles module is off, there is nothing to write, or the write fails — everything else still routes, and the submission's review screen says what happened and why. (On an event form, "nothing to write" almost never happens: the event answers themselves are enough to build an article even when no question is mapped to an article field at all.)

When auto-commit is off (the default), the article is created at the moment you commit the submission, not when it arrives.