Read this first: an independent writing sample for EULER's Technical Writer role, not published or endorsed by EULER. It covers 13 gaps found in support.eulerapp.com as of 10 November 2026, and every page is free to reuse. Every behavior comes from a public EULER source, listed on each page. Anything a public source does not settle carries a VALIDATE flag instead of a guess.
Start here
13 gaps in the EULER help center, and a sample page for each
I read support.eulerapp.com against eulerhq.com, the API Reference and the MCP connector reference, and found 13 things a customer, partner or developer needs that the help center does not yet give them. Each gap has a sample page here, written to sit beside the docs that already exist and link to them.
Reviewed 10 Nov 2026Samples 13Status SAMPLE - NOT OFFICIAL
Already strong: PAM and POPS, Webhooks, Forms 2.0, Flows, MCP setup, and the partner guide to submitting a referral. None of them is rewritten here.
Biggest gap: DealFlow AI, a headline feature on eulerhq.com, has no help center article. Its email intake appears only as a form type called "AI Email Parse" inside Forms 2.0.
Most expensive gap: the API & Webhooks collection documents a token API that takes a user's email and password, while the API Reference documents API v1 with revocable, scoped keys. A developer who starts in the help center builds on the older one.
Easiest gap to see: the Change Log, linked as "Release notes", ends on 19 March 2026.
Every sample is yours to use, edit and publish, with or without me. Download them all as Markdown, ready to paste into Intercom Articles, Notion or a docs repo. Each page also has its own download link at the top.
No invented interface. Where a page needs a menu path, address or label that no public source gives, it carries a VALIDATE flag instead of a guess.
Engineers get statements, not meetings. Each page ends with a short "Confirm with engineering" list, answered yes, no, or correct me.
One job per page, with the reader, the result and what can go wrong on the first screen, a check after every step, one labelled wrong example, and a next page.
Shall and should mean different things.Shall marks what the procedure depends on. Should marks a recommendation.
Limits
I had no product access, ticket data or search analytics, so "biggest" and "most expensive" are judgments from public pages, not measurements. Every UI path not shown in a public source is flagged.
About the author
Bachtiar Widyantoro writes technical documentation and B2B technical content. He spent ten years as a field engineer in lightning protection, earthing and SCADA, writing method statements, survey reports and as-built documentation, and running his company's website. He built this set for EULER's Technical Writer role.
Whether or not we end up working together, I just hope this helps in your success.
You finish this page with one pilot partner approved, invited, and through their first referral, with the referral sitting in your CRM. Each step links to the detailed article that already exists. This page supplies the order, because most setup mistakes in EULER come from doing the right steps in the wrong sequence.
Gap 1 of 13Reader New EULER adminResult One partner live, end to end
The help center has a partner "Start Here" page and detailed admin articles, but no admin path. A new admin who approves a partner before the CRM is connected, or publishes a form before testing its CRM mapping, creates records that have to be fixed by hand. Forms 2.0 says Forms will not work at all until a CRM is connected, and that warning sits halfway down a long article.
What exists today, and is linked rather than repeated
You are an admin on your EULER workspace. VALIDATE ROLE NAME
You can sign in to your CRM (Salesforce, HubSpot or Pipedrive) as a user whose permissions EULER should inherit. EULER acts with the permissions of whoever authorizes the connection.
You have one real pilot partner. A real partner finds setup problems a test account does not.
Your partner agreement exists as a document.
What can go wrong
A form question mapped to a CRM field that does not exist makes the form's CRM sync fail. Forms 2.0 has a Test button for exactly this.
In Salesforce, a Lead that already has the applicant's email makes partner creation fail with a duplicate error. See Salesforce setup checks.
Choosing Mark as Approved on a potential duplicate changes the status only. It creates nothing in EULER or your CRM.
Steps
Connect your CRM first
Go to Integrations, find your CRM and click Integrate, then authorize it (Salesforce, HubSpot). You shall do this before building any form: Forms require an active CRM integration, because answers are written straight to the CRM. You should authorize with an integration user rather than a person, so the connection does not break when that person leaves.
Check: the CRM shows as connected on the Integrations page, under the user you intended.
Build and test the partner registration form
Go to Settings > Forms, click + New Form, and choose the Partner Registration type. It starts with First Name, Last Name, Email and Company. Give every question an API Value that exactly matches a field on the CRM object. Then click Test: it submits sample answers to your CRM with your mappings.
Check: the test record appears in your CRM with every answer in the field you mapped. If you edit a mapped question afterwards, test again.
Create the agreement template and decide whether it locks the portal
Create the template (see Create an Agreement Template). The template shall have your company signature on file: a template without one cannot be sent. Decide now whether partners can use the portal before signing. EULER can lock the portal until the agreement is signed.
Check: the template shows a company signature, and you have written down whether it restricts portal access.
Build the onboarding flow and make it a Standard Flow
Build a short flow: agreement first, then only the training a partner needs before their first referral. Publish it (status Active). Add it to your Standard Flows, the default set EULER assigns automatically when a partner joins the portal, so you never have to assign it by hand. VALIDATE MENU PATH
Check: the flow is Active and listed as a Standard Flow.
Give PAM something to answer from
Add at least your program terms and your referral rules as PAM knowledge sources, so the partner's first questions get answers from your content (see PAM AI Knowledge Sources).
Check: each source shows as active. A source that never finished indexing is not used.
Publish the form and send it to the pilot partner only
Toggle the form to Active, then send the pilot partner the form link or embed it with Get Code (see Embed Euler Form). Keep it to one partner until step 9 passes.
Check: the partner's submission appears as a new partner application for you to accept.
Approve the application, knowing what approval does
Approving runs onboarding: EULER finds or creates the partner and partner contact from the answers, syncs to your CRM, applies tags and creates an affiliate link. If EULER flags a Potential Duplicate, choose Proceed with Creation to create or reuse the CRM records. Mark as Approved creates nothing.
One exception: on a Salesforce form that creates partners in the CRM only, approval creates only the Salesforce record. The partner appears in EULER when the sync brings it back.
Check: the partner exists once in EULER and once in your CRM, and has an affiliate link. In CRM-only mode, the Salesforce record exists and the EULER record follows.
Invite the partner's contacts to the portal
Invite the people who will submit referrals. If you would rather introduce EULER yourself, you can skip the invite email. VALIDATE OPTION LABEL
Check: the contact's invitation shows as accepted. If it does not, ask POPS why the partner cannot access the portal (see Troubleshooting Partner Access Issues with POPS AI): it reports bounced or never-activated invites and pending agreements.
Run one real referral end to end
On a short call, have the partner submit one real referral, from the portal or by forwarding an email (see DealFlow AI). Approve it from Referrals to Approve (see Referral Approval).
Check: the referral is approved in EULER, and the CRM record it should create exists with the partner attached.
What wrong looks like
WRONG - SETUP ORDER
1. Invite 40 partners from a spreadsheet
2. Build the registration form
3. Connect Salesforce
4. Approve the applications that came in
Why it fails: in Forms 2.0, Forms cannot be used until a CRM
is connected, so step 2 stalls. When it does work, 40 partners
meet an untested form, and any duplicate or mapping error is
now 40 records to fix by hand. Connect, build, test, then
prove it on one partner.
Check your work
CRM connected under the intended user.
Registration form passed its Test, and nothing mapped changed since.
Agreement template has a company signature and a decided portal-lock setting.
Onboarding flow is Active and a Standard Flow.
Pilot partner exists once in EULER and once in the CRM, with an affiliate link.
One referral approved, with its CRM record and the partner attached.
Confirm with engineering
The role that can connect integrations and approve applications is [role]. Correct me.
Standard Flows are managed at [menu path]. Correct me.
The option to skip the partner invite email is labelled [label] and sits at [location]. Correct me.
Approving an application always creates the affiliate link at approval, outside CRM-only mode. Yes / no / correct me.
Pipedrive uses the same Integrations > Integrate path as Salesforce and HubSpot. Yes / no / correct me.
Register a referral or deal from an email, Slack, or any webpage (DealFlow AI)
You finish this page with a referral or deal registration submitted without filling in a form, waiting in your partner's approval queue with you attached as the partner. DealFlow AI reads what you already wrote and builds the registration from it. The second half of the page is for admins: how submissions arrive and what to check.
Gap 2 of 13Reader Partners, then adminsYou need An email thread, a Slack message, or a webpage about the lead
eulerhq.com presents DealFlow AI as registration without the form, and its FAQ answers "Can partners register a deal by email?" with yes. But no help center article carries the DealFlow name. A partner who hears about it in an onboarding call and searches the help center finds nothing. The pieces exist in four places that never mention each other:
Forms 2.0 mentions an AI Email Parse form type, "used for Euler's email-based referral parsing", one per account.
Your partner gave you the address to forward to. VALIDATE ADDRESS FORMAT
For Slack: you have installed Euler for Partners from Partner Portal > Settings > Slack, or you share a Slack Connect channel your partner has mapped to you. In a mapped Slack Connect channel you do not need to install anything.
You have the lead's correct email address. EULER uses it to check whether the lead is already in your partner's CRM.
What can go wrong
A typo in the lead's email is the usual cause of a false duplicate, and of a missed real one.
A thread with no named contact and no stated need gives DealFlow nothing to extract, and the reviewer nothing to approve.
Nothing is approved automatically. Until your partner's team decides, the submission is pending.
Method 1: forward an email
Choose the thread that shows intent
Use the thread where the prospect asks for something: a demo, pricing, an introduction. No format is required, but the thread shall name the contact and their company.
Check: someone who has never seen the thread could name the company, the person and what they want.
Forward it, or CC EULER on the thread
Forward the thread to your partner's EULER address, or CC that address on your reply. You should add one line at the top with what the thread does not say: rough size, timing, and whether you are handing the lead over (referral) or working it yourself (deal registration).
Check: the email went to the address your partner gave you, not to a person.
Confirm it arrived
EULER does not send a confirmation email for submissions. Check your portal, or ask PAM: "show my pending referrals" (see Tracking Your Referrals and Deals).
Check: the referral or registration appears as pending, with your company as the partner.
EXAMPLE - FORWARDED INTRO
To: [your partner's EULER address]
Subject: Fwd: Intro - Northwind Freight
Context: deal registration, I'm working this one.
About 40 seats, they want to decide this quarter.
---------- Forwarded message ----------
From: Dana Reyes <dana.reyes@northwindfreight.example>
Subject: Re: Intro
Thanks for the intro. Our ops team would like a demo
next Tuesday. Procurement will join.
Northwind Freight is a fictional company. The .example domain is reserved for documentation.
Method 2: from Slack
Start from the message, or from scratch
In your own workspace, use the Send referral with AI shortcut on the message about the lead. With no message to start from, type /referral. VALIDATE WHERE THE SHORTCUT APPEARS
Check: a referral form opens in Slack.
Review what was extracted
The form opens with name, email, company and other fields filled from the message. Every field is editable. You shall check the email address before submitting.
Check: the email matches the lead's real address, and the company name is the one the customer uses.
Submit
The Slack message updates by itself when your partner approves or rejects it.
Check: the message shows the pending status.
Method 3: from a webpage
With the browser extension installed, open it on the prospect's page (a LinkedIn profile, a company site) and submit from there. VALIDATE INSTALL LINK AND STEPS
Method 4: tell PAM
Describe the lead to PAM the way you would tell a colleague. PAM extracts the company, contact, role and context, shows you the referral, and asks you to confirm before submitting.
What wrong looks like
WRONG - SLACK MESSAGE SENT FOR EXTRACTION
big logistics co is interested, talk to Dana, soon
Why it fails: no company name, no email, no role, no ask.
DealFlow has nothing to extract, the duplicate check has
no email to match, and the reviewer has nothing to approve.
Name the company, the person with their email and role,
what they asked for, and when.
For admins: what arrives, and what to check
Everything lands as pending in your approvals, from every method. DealFlow creates registrations. It cannot approve them.
The partner is attached at creation, so attribution does not depend on a rep remembering to tag it.
Duplicates are flagged at intake against your CRM, matched on email. Resolve them the same way as any other submission: see Referral statuses.
Email intake uses the AI Email Parse form type. Only one is allowed per account, and its questions decide what reaches your CRM. VALIDATE: IS IT REQUIRED FOR EMAIL INTAKE
Your team can create referrals from Slack too: on a partner's message, choose Create Referral from Message, pick the partner, review, and submit.
Confirm with engineering
Each customer gets one DealFlow address in the format [format], shown at [location]. Correct me.
Email intake requires an active AI Email Parse form. Yes / no / correct me.
A forwarded email is submitted as soon as it is parsed, with no review step for the partner. Yes / no / correct me.
DealFlow decides between referral and deal registration from [rule]. Correct me.
When an email cannot be parsed, the sender is told by [channel]. Correct me.
The browser extension is the same as the "Euler Chrome Extension" in Inbound Referral Management. Yes / no / correct me.
eulerhq.com/ai-agents/dealflow-ai and its FAQ: forward or CC, no format required, Slack actions and /referral, browser extension, pending until approved, Slack message updates, email used for duplicate matching, registrations can expire.
Pipedrive integration: data flow (draft for engineering review)
This page is deliberately a draft. Public sources say EULER supports Pipedrive but say almost nothing about how. So the sample shows the other half of the job: a page structured to match the existing Salesforce and HubSpot Data Flow articles, with every fact sourced and every unknown turned into a question engineering can answer in one sitting.
Gap 3 of 13Reader Admin or RevOps on PipedriveState Draft, about two-thirds questions
Forms 2.0 names Pipedrive as one of the three CRMs Forms work with. eulerhq.com lists Pipedrive under CRMs and says the CRM integrations are bidirectional and map to any object or field. Yet the Integrations collection has HubSpot (6 articles), Salesforce (3) and QuickBooks (2), and nothing for Pipedrive. Potential Duplicate explains duplicate handling for HubSpot and Salesforce only, so a Pipedrive admin cannot tell what happens when an applicant already exists.
Sample documentation starts here
Overview
EULER connects to Pipedrive so partner records, partner contacts and partner deals stay in sync, and so EULER Forms can write submissions into Pipedrive. VALIDATE AUTH METHOD Pipedrive's own objects are Organizations, People, Deals and Leads. The table below is the mapping engineering needs to confirm.
How EULER reads from Pipedrive
EULER record
Pipedrive object
How EULER identifies it
Fields read
Partner
[Organization?]
[label, custom field, or filter]
[name, ID, created, modified]
Partner contact
[Person?]
[linked to the partner Organization]
[first, last, email, title]
Partner deal
[Deal]
[custom field linking the deal to the partner]
[title, value, stage, pipeline, close date]
How EULER writes to Pipedrive
Writes go through EULER Forms. Each question's API Valueshall match a real field key on the Pipedrive object, or the form's CRM sync fails. Run the form's Test before publishing. Both rules come from Forms 2.0 and apply to every CRM.
Which objects can a form write to: [Organization, Person, Deal, Lead?]
Are custom fields addressed by their Pipedrive field key or their name? [key / name]
Duplicates
[What EULER searches before accepting a Partner Registration or Referral submission in Pipedrive, and which of Proceed with Creation, Mark as Approved and Reject are offered. This section should be added to Potential Duplicate as a third CRM.]
What wrong looks like
WRONG - PUBLISHING THIS PAGE AS IT IS
"EULER syncs your Pipedrive Organizations, People
and Deals in real time."
Why it fails: no public source says which objects,
which direction, or how often. A confident sentence
that turns out wrong costs more support tickets than
the missing page did. Brackets stay until confirmed.
Confirm with engineering
Fifteen minutes of answers turns this draft into the page.
Pipedrive connects through OAuth from Integrations, like Salesforce and HubSpot. Yes / no / correct me.
Partners are Organizations identified by [label / custom field]. Correct me.
Partner contacts are People linked to that Organization. Yes / no / correct me.
A deal is attributed to a partner through [field]. Correct me.
Forms can write to Organizations, People, Deals and Leads. Correct me with the list.
The duplicate check matches People on email and Organizations on name and/or website, as for HubSpot. Yes / no / correct me.
Sync runs [in real time / every n minutes]. Correct me.
EULER inherits the permissions of the Pipedrive user who connects. Yes / no / correct me.
Salesforce: setup decisions, and what to check when records don't appear
Connecting Salesforce takes four steps. The failures come later, from five decisions nobody made on purpose: whose permissions EULER inherits, how partners are identified, how deals point to partners, which referral flow you use, and how your duplicate rules treat an API. Make them before go-live, then use the table at the end when something goes missing.
Gap 4 of 13Reader Salesforce admin, RevOpsBuilds on Salesforce Integration: Data Flow
Salesforce has three articles: Salesforce, Connecting Salesforce to Euler (ECA), and Salesforce Integration: Data Flow, which says what EULER reads and that it writes through Forms. What is still missing is the consequence of each setup choice, and a fix path. The Salesforce-specific rules that cause failed approvals are inside Potential Duplicate, where an admin looking at a missing partner will not think to look.
Sample documentation starts here
How EULER sees your Salesforce
Permissions: EULER connects through OAuth and inherits the permissions of the user who authorizes it. Anything that user cannot see, EULER cannot see.
Reads: the partner object (usually Account, sometimes a custom object), partner Contacts linked by Account ID, and Opportunities linked to partners through a partner lookup field.
Writes: through EULER Forms only. Each question writes to the field named in its API Value, and add-ins set default values no question asks for, such as Type = Partner.
Five decisions to make before go-live
Choose the connecting user
You should connect with a dedicated integration user whose profile can see every partner Account, Contact and Opportunity. A personal account limits EULER to that person's visibility, and the sync stops if the person leaves.
Check: logged in as that user, you can open a partner Account, its Contacts, and an Opportunity owned by someone else.
Decide how EULER recognizes a partner
On the Account object, EULER identifies partners by a record type ID or by a picklist value such as Type = Partner. You shall pick one, apply it to every existing partner, and set the same value as an add-in on your Partner Registration form, so new partners are classified the same way.
Check: a list view filtered on your rule shows every partner you expect, and nothing else.
Give Opportunities a partner lookup field
EULER links an Opportunity to a partner through a partner lookup field. A deal with that field empty is invisible to partner reporting and commissions. You shall have the field, and your team should fill it on deals created outside EULER.
Check: pick three partner deals created by reps. All three have the lookup filled.
Choose the referral flow
An approved referral either creates a Contact, Account and Opportunity, or creates a Lead. The two behave differently on duplicates (next step). Choose the one your sales process already uses.
Check: your referral form's mappings write to the objects of the flow you chose, and its Test passes.
Check your duplicate rules against API behavior
Salesforce lets a person override a duplicate warning in the UI, but not an API (see Salesforce's DuplicateRule reference). Two rules follow, from Potential Duplicate:
If a Lead has the same email as a partner applicant, convert that Lead to a Contact before accepting the application, or Salesforce returns a duplicate error and partner creation fails.
In the Lead referral flow, Proceed with Creation works only if your duplicate rule allows duplicates. Otherwise create the Lead by hand and choose Mark as Approved.
Check: you know which of your duplicate rules apply to Leads, and whether they block or alert.
CRM-only partner creation
A Salesforce Partner Registration form can create partners in Salesforce only. Then approving an application creates the Salesforce record and nothing in EULER. The partner appears in EULER when the sync brings the record back, and the application may show creating or approved without a partner in the meantime. Tell your support team which mode you use: a missing partner means opposite things in the two modes.
What wrong looks like
WRONG - FORM MAPPING
Question "Company size" API Value: Company_Size
Field on the Account: Company_Size__c
Why it fails: the API Value must exactly match a real field
on the object. Custom fields in Salesforce end in __c, so
this answer has nowhere to go and the form's CRM sync fails.
Use the field's API name, Company_Size__c, and run Test.
When a record doesn't appear
Symptom
Likely cause
Fix
Partner approved, in Salesforce, not in EULER
CRM-only creation mode. The sync has not returned the record yet.
Confirm the mode, wait for the sync, then check again. If it never arrives, check the record matches your partner rule (decision 2).
Partner approval failed with a duplicate error
A Lead has the applicant's email.
Convert the Lead to a Contact, then accept again.
Referral approved, no Lead created
Your duplicate rule blocked the API.
Create the Lead by hand and choose Mark as Approved, or relax the rule for the integration user.
Status shows error writing to crm
An API Value that does not match a field, or a required field the form does not fill.
Open the form, fix the mapping, run Test, then retry.
Deal in Salesforce, not in the partner's view
The partner lookup field is empty.
Fill the lookup. The deal syncs with the partner attached.
Some partners or deals never appear
The connecting user cannot see them.
Widen that user's access, or reconnect as an integration user.
Confirm with engineering
The CRM-only option is set on the Partner Registration form, at [setting]. Correct me.
EULER reads Salesforce every [interval]. Correct me.
"error writing to crm" is the status shown when a mapped write fails. Yes / no / correct me.
Filling the partner lookup on an existing deal attaches it to the partner at the next sync. Yes / no / correct me.
The ECA connection in "Connecting Salesforce to Euler (ECA)" replaces the OAuth steps in "Salesforce", or applies to [case]. Correct me.
Salesforce, and Salesforce Integration: Data Flow: OAuth, inherited permissions, objects read, record type or Type picklist, partner lookup field, Forms writes and add-ins.
Potential Duplicate: Lead conversion rule, the two referral flows, duplicate rules and the API.
Forms 2.0: API Value must match a real field; Test. API Reference: referral statuses include "error writing to crm". MCP reference: CRM-only partner creation and the "creating" status.
Gap samples / Gap 5 - Rewards (admins and finance)
How incentives and commissions work in EULER
This is a concept page: read it before you build a program in Program Builder. It explains the two incentive systems EULER runs, how a commission comes out of a charge, and which way a commission flows. It ends with the questions to answer before you configure anything.
Gap 5 of 13Reader Admin, partner ops, financeType Concept, then checklist
The partner side is documented: Your Incentive Plan and Partner Tier. The admin side is not. eulerhq.com lists revenue share, flat fees, per-product rates, tiers, SPIFFs, MDF and gift cards, and the MCP reference shows that a company runs one of two incentive systems, called 1.0 and 2.0, which count and calculate differently. No help article names either.
Sample documentation starts here
The model in one paragraph
A charge is revenue on a deal, usually read from your billing integration. An incentive attached to the partner says what share of that charge they earn. The result is the charge's commission to be paid. Pending payouts queue for approval (see Approving Invoices), then go out through EULER Pay, a gift card, your accounting system, or an exported file. The partner sees earned, pending and paid amounts in their portal.
Your company runs one of two systems
Incentives 1.0: tier packages
Incentives 2.0: programs
Unit
A tier package
A program, made of tiers
Rate depends on
Revenue ranges: each has a minimum, maximum, commission %, flat payout and net days
One row per product group, revenue range and time period, so a partner can hold several rates at once
Payment terms
Payout frequency and net days after payment, on the package
VALIDATE
Extras
None listed
Tier benefits, boost or override campaigns
Moving up
By revenue range
Advancement rules per tier, with a goal and live progress for each
"Partners per tier" counts
Distinct partners on each package
Active assignments on each tier
A company runs exactly one system. Check which one before you read any other incentives guide, because the counts and the setup differ.
Worked example
Fictional numbers, to show the arithmetic only. A partner on a 10% revenue-share line closes a deal billed at $20,000.
EXAMPLE - ONE CHARGE, ONE COMMISSION
Charge amount 20,000.00 USD (from billing)
Commission rate 10% (partner's incentive line)
Commission to be paid 2,000.00 USD = 20,000 x 0.10
Charge type: Referral the partner sent you the deal,
so you owe the partner.
With Incentives 2.0, the same partner can hold a second line for another product group, so two charges on one deal can carry two rates. Read each charge's own rate. Never apply one percentage to a whole deal.
Which way a commission flows
Charge type
Who sent the deal
Who owes the commission
Referral
The partner, to you
You owe the partner
Reseller
The partner, to you
You owe the partner
Outbound
You, to the partner
The partner owes you
What wrong looks like
WRONG - COMMISSION REPORT
"Total commissions this quarter: 48,300 USD"
(sum of every charge's commission, all charge types,
across two currencies)
Why it fails: Outbound commissions are owed TO you, so
adding them to Referral and Reseller commissions mixes
money in with money out. And amounts in two currencies
cannot be added. Report each direction separately, in
each currency.
Before you build a program
You know whether your company runs Incentives 1.0 or 2.0.
Your billing integration is connected, so commissions calculate on billed revenue rather than retyped amounts.
Each partner type has its own structure written down: rate, what it applies to, and the period.
Tier rules are written as goals a partner can see, not as judgments made at review time.
You have chosen a payout route and who approves pending payouts.
Confirm with engineering
An account's incentive system (1.0 or 2.0) is shown at [location], and moving between them is done by [team / process]. Correct me.
In 1.0, the revenue range is measured against [cumulative / per-period] revenue, and the whole amount is paid at the range's rate. Yes / no / correct me.
In 2.0, a boost campaign [adds to / replaces] the tier rate for its period. Correct me.
Commission is calculated when [the deal closes / the charge is recorded / the invoice is paid]. Correct me.
eulerhq.com/lifecycle/reward: incentive structures, billing integration, bulk approval of pending payouts, four payout routes, partner view.
MCP connector reference: incentives_summary, partner_inc1_incentives, partner_inc2_incentives (1.0 and 2.0 structure, one system per company); commissions (charge_type directions, currencies never added).
Set up MDF and CIF funds, and decide on fund requests
You finish this page with one fund your partners can request against, an approver assigned, and a first request taken from submission to a decision. MDF is a Market Development Fund: money a partner spends on marketing for you. CIF is a Co-op Investment Fund. Both run on the same request flow.
Gap 6 of 13Reader Admin, partner marketing, financeResult A live fund and one decided request
Funds appear in the help center only inside AI articles: PAM: Incentives, Funds (MDF/CIF) & Service Projects and the MCP prompt guides for requesting and deciding. Forms 2.0 lists a Fund Request form type. Nothing tells an admin how to set up a fund, who approves, or what each step of a request means.
Sample documentation starts here
How a request moves
A fund has a budget, a status, period dates and a request form. A partner's request moves through ordered steps. Each step is either the partner's to act on or yours.
01
Request
Partner fills the fund's form
02
Approve
Your approver decides
03
Execute
Partner runs the activity
04
Proof
Partner uploads evidence
05
Reimburse
You pay out
06
CIF only
Assign the resulting deal
Which steps a fund uses depends on how it is configured. VALIDATE STEP ORDER
Before you start
A connected CRM. A Fund Request form is a Form, and Forms need one.
A budget figure and a period for the fund.
A named approver. Only a user configured as an approver for the step can decide it.
What can go wrong
No approver assigned: requests wait on a step nobody is allowed to complete.
Paying before proof of performance turns co-marketing into a subsidy you cannot defend to finance.
Some steps can be finished only in the EULER web app, not through PAM or POPS: customer upload, reimbursement, and assigning a deal to a CIF.
Steps
Build the request form
In Settings > Forms, create a form of type Fund Request (see Forms 2.0). Ask for what you need to approve: the activity, the expected result, the amount and the dates.
Check: the form's Test passes.
Create the fund
Create an MDF or CIF fund with its budget, period dates and the form from step 1, and set which partners are eligible and for how much. VALIDATE MENU PATH
Check: the fund is active, and an eligible partner can see it in their portal or by asking PAM which funds are available.
Assign approvers to each approval step
Name at least one approver per approval step. You should set an amount below which requests clear on their own, so small requests do not wait on a manager. VALIDATE THRESHOLD SETTING
Check: every approval step shows a named approver.
Decide the first request
A submitted request appears as pending against its fund. Read the partner's answers, then:
Approve completes the approval step and the request moves on.
Reject ends the request.
Request info asks the partner for documents or notes. It is not a decision: the request stays on the same step and waits on the partner, and you can still approve or reject after.
Check: the request shows the next step, or shows waiting on the partner.
Gate payment on proof
Payment shall wait until the partner's proof of performance is approved. Then complete reimbursement in the web app.
Check: the fund's paid amount rose by the request amount, and its remaining budget fell by the same.
Budget words
Committed is approved but not yet paid. Paid has gone out. Remaining is budget minus committed minus paid. VALIDATE FORMULA
What wrong looks like
WRONG - APPROVER NOTE
Approved. Pay once the webinar is done.
Why it fails: "done" is not evidence, and the note is
private to your team. Use Request info on the proof step
and list what counts as proof: the recording link, the
registrant count, the attendee list.
Confirm with engineering
Funds are created at [menu path]. Correct me.
The auto-approve threshold is set per [fund / step]. Correct me.
Partners write their own listings. Your job is to approve or reject their edits, hide listings that should not show, feature the partners you want buyers to see first, and set tiers. This page explains the five profile statuses and what each moderation action does to them.
Gap 7 of 13Reader Admin who owns the directoryResult A review queue at zero, listings you stand behind
Published. Admin edits publish straight to Active.
Yes
Under Review
A partner edited their profile and it waits for you.
VALIDATE: OLD VERSION OR NONE
Awaiting Setup
A profile exists but the partner has not filled it in. VALIDATE
No VALIDATE
Rejected
You rejected the partner's edit, with a message.
VALIDATE
Hidden
You hid it. Unhiding restores the status it had before.
No
Before you start
The Partner Directory is part of your plan. It is an optional add-on.
You have decided which listing fields, filters and regions partners fill in. Structured fields keep listings comparable. Freeform copy does not.
What can go wrong
The public directory rebuilds on a cycle of about ten minutes. A change you just made will not show at once: wait before you call it broken.
Editing a listing yourself publishes immediately, with no review. That is right for fixing a typo, wrong for rewriting a partner's claims without telling them.
A profile with no linked partner record cannot be tied to that partner's deals or referrals.
Steps
Work the Under Review queue
Filter the directory by Under Review. For each profile, compare the edit with what you know about the partner: services, regions, certifications. VALIDATE FILTER LOCATION
Check: you can see the list of profiles waiting for you.
Approve, or reject with a reason
Approve to publish. To reject, you shall write a message the partner can act on: what to change, not only that it was refused.
Check: the queue count dropped by one, and the profile shows Active or Rejected.
Hide what should not show
Hide a profile for a partner who has left, or is paused. Hide works only on a profile that is not already hidden, and Unhide only on a hidden one, returning it to its earlier status.
Check: after about ten minutes, the listing is gone from the public directory.
Feature partners, and set tiers
Feature the partners buyers should see first. Set a tier so buyers can tell partners apart by something they did not self-report.
Check: featured partners sort first when buyers sort by featured.
Add profiles for partners you already work with
Create empty profiles for existing partners, so they have something to complete rather than something to start. VALIDATE RESULTING STATUS
Check: each new profile is linked to its partner record.
Resource types
A listing can carry seven kinds of resource: Testimonial, Resource, Case Study, Client, Video, Top Service and Certification. You can switch off a type for the whole directory, and its section disappears from every profile.
What wrong looks like
WRONG - REJECTION MESSAGE
Rejected. Please revise.
Why it fails: the partner cannot tell what to change, so
the next edit fails the same way. Say what to fix: "Remove
'certified in all products'. You hold the Implementation
certification only, which we show on your listing."
Hosting the directory on your own site
To render the directory in your own front end, use the Partner Directory endpoints in the API Reference. Call them from your server, never with a full-access key in the browser, and send usage events back so the directory's analytics in EULER stay populated.
Confirm with engineering
While a partner's edit is Under Review, buyers see [the last approved version / nothing]. Correct me.
A profile created for an existing partner starts as Awaiting Setup. Yes / no / correct me.
A Rejected profile stays [visible with the old content / hidden]. Correct me.
The Under Review filter is at [location] in the web app. Correct me.
Referral and deal registration statuses: what each means, and what to do
A reference page. Look up the status a submission shows, read what it means, and do what the last column says. The second table starts from a symptom instead, for when something is missing and you do not know its status yet.
Gap 8 of 13Reader Admin working the approvals queue, supportType Reference
The queue itself is documented: Referral Approval covers accept and reject, and Potential Duplicate covers the three duplicate choices. What no page says is what each status means once it is set. The status values appear only in the API Reference and the MCP reference, so support cannot point a customer to them. One consequence goes unexplained: Mark as Approved sets the status to approved and creates nothing.
Sample documentation starts here
Statuses
Status
What it means
What to do
pending
Submitted, waiting for a decision. Every channel lands here: portal, embedded form, email, Slack, PAM. Nothing approves on its own.
Accepted, and EULER is still writing it. API-created referrals show this until checks finish. For partner applications on CRM-only Salesforce forms, the CRM record was written and the partner arrives later through the sync.
Wait, then check again. Do not accept it a second time.
approved
Accepted. Either EULER created the CRM records, or someone chose Mark as Approved, which creates nothing.
If no CRM record exists, it was marked rather than created. Create the record in the CRM by hand.
duplicate found
The CRM already has a match, on email for contacts, and on name or website for companies.
Choose: Proceed with Creation (create or reuse the CRM records), Mark as Approved (the record already exists, create nothing) or Reject.
error writing to crm
Accepted, but the CRM refused the write.
Fix the cause, usually a form mapping or a CRM duplicate rule, then retry. See the symptom table below.
rejected
Declined. If the form has rejection reasons configured, one was required.
Nothing, unless the partner asks why. Send the reason when you reject, not later.
Drafts are not submissions: they never appear in the queue or in counts.
Referral or deal registration
Both use these statuses. A deal registration also expires after the window you set, because it claims an opportunity the partner is working. A partner still working a deal near expiry should ask their Partner Manager before it lapses, because protection does not carry forward on its own.
Accepting and rejecting well
Read the duplicate warning before you click. EULER checks your CRM on the referred contact's email before you decide.
Associate the partner when a submission from an external form came from an email address EULER does not recognize. Use Associate Partner before accepting, so attribution is right from the start.
Send a message on rejection. You can notify the partner when you accept or reject. A reason they can act on keeps the next referral coming.
Outbound referrals reverse the roles. For a referral you sent to a partner, the partner decides, and the form answers stay hidden from them until they accept.
When something is missing
Symptom
Most likely cause
Fix
Partner says they submitted, you see nothing
Submitted to a different company's portal, or still a draft. Email submissions get no confirmation email.
Ask PAM or POPS for that partner's referrals in both directions.
Approved, nothing in the CRM
Marked as Approved rather than created.
Create the record in the CRM by hand, with the partner attached.
The partner link on the CRM deal is empty, or the affiliate link's tracking id was not captured.
Fill the partner link on the deal. For affiliate traffic, check the tracking script is installed on the page (affiliate attribution).
What wrong looks like
WRONG - CLEARING THE QUEUE
"Duplicate found" on 12 referrals
-> Mark as Approved on all 12, to clear the queue
Why it fails: Mark as Approved creates nothing. Any of the
12 that were not really in the CRM are now approved,
attributed nowhere, and invisible to sales. Mark as
Approved only the ones you have confirmed exist in the CRM.
Confirm with engineering
The web app shows these statuses with the same wording as the API. Yes / no / correct me with the labels.
"duplicate found" is set before a decision, and "error writing to crm" after one. Yes / no / correct me.
A referral in "error writing to crm" can be retried from [location]. Correct me.
Rejection reasons are configured per form at [location]. Correct me.
API Reference: GET /v1/referrals status values, drafts excluded, conditional rejection reason, outbound answers hidden until accepted, POST /v1/referrals returns 202 and status "creating".
Which EULER API to use, and your first three calls
The help center documents two different APIs without saying so. This page tells them apart, says which one new work should start on, and takes you from an API key to a submitted referral in three calls.
Gap 9 of 13Reader Developer, RevOps engineerResult A working key and one referral created
The API overview exists: the API Reference is thorough, with keys, scopes, errors, rate limits and OpenAPI. The gap is what sits next to it. The help center's API & Webhooks > Authentication article, updated 27 Aug 2026, documents a different API: you send a user's email and password to eulerapp.com/api/1.1/wf/generate-api-token and get a token valid for a year. A developer who starts in the help center builds on that one, and puts a password into a script to do it.
Sample documentation starts here
The two APIs
API v1
Workflow endpoints
Base URL
https://api.eulerapp.com/v1
https://eulerapp.com/api/1.1/wf/...
Auth
API key from Settings > API access, sent as Authorization: Bearer
A user's email and password, exchanged for a token
Lifetime
No scheduled expiry. Revoke one key without touching others.
Token valid one year
Scope
Full access, or restricted to chosen endpoints
Acts as the user
Documented in
api.eulerapp.com/docs
Help center: Authentication, Charges, eid, HubSpot Charges
New integrations should start on API v1: it is the API the help center's own "API Reference" link points to, and it never needs a password. API access is in beta. If API access is missing under Settings, ask EULER support in your shared Slack channel to turn it on.
Before you start
API access is enabled on your account.
You will call the API from a server. A full-access key acts as you, so it never goes in browser code.
What can go wrong
A key is shown once, when you create it. Lost it? Create a new one and revoke the old.
Creating a referral is asynchronous. A retry without an Idempotency-Key can create a second referral.
An expired key and a revoked key both return 401 invalid_token. The message tells them apart. Retrying an expired key never helps.
Steps
Create a key and confirm it works
In Settings > API access, click New key and name it after the integration. Create one key per integration, so you can revoke them one at a time. Then call GET /v1/me.
Check: a 200 whose data names you and your company. Every successful response has a top-level data field.
Find the form and its questions
A referral answers a partner's referral form. List the partner's forms, then fetch the questions of the one you want. Each question's input_type says which field carries its answer.
Check: you have a form id, and a question_id for every question marked required.
Create the referral, then poll it
Send one answer per question, with a unique Idempotency-Key. Free-text answers go in answer_text, dropdown and multiselect answers in selected_options.
The response is 202 Accepted with the referral's id, while EULER runs its checks. Poll GET /v1/referrals/{id} until status is no longer creating.
Check: the referral reaches pending and appears in the web app's approvals queue.
Question ids above are placeholders. Use the ids step 2 returned.
What wrong looks like
WRONG - AUTH IN A SCHEDULED SCRIPT
curl -X POST https://eulerapp.com/api/1.1/wf/generate-api-token \
-d '{"email":"ops-lead@yourco.example","password":"..."}'
Why it fails: a person's password now lives in a script,
the token acts as that person for a year, and revoking it
means changing their password. With API v1, create a key
restricted to the endpoints the script calls, and revoke
just that key when the script retires.
Errors to branch on
Response
Meaning
Do
401 invalid_token, "invalid or revoked"
Wrong secret, or revoked
Check which key you send
401 invalid_token, "can no longer authenticate"
Key expired
Create a new key, switch, revoke the old
403 insufficient_scope
A restricted key called an endpoint it was not granted
Add the endpoint to the key's scopes
409 idempotency_conflict
A retry arrived while the first request was still running
Retry later with the same key
422 validation_failed
An answer is missing or invalid. details names each question_id.
Fix those answers
Confirm with engineering
The workflow endpoints are [deprecated on date / supported], and the help center articles should say so. Correct me.
POST /v1/payments replaces the workflow Charges endpoint. Yes / no / correct me.
The HubSpot-Reward webhook has a v1 equivalent at [endpoint], or stays on the workflow API. Correct me.
The API & Webhooks collection can link each legacy article to its v1 page. Yes / no.
Reseller and AWS Marketplace deals: how they fit in EULER
A short guide for an admin adding a reseller channel or an AWS Marketplace motion to a program that already runs referrals. It says which EULER features each motion uses, routes you to the pages that set them up, and lists the setup questions to answer first.
Gap 10 of 13Reader Admin, alliances leadType Guide (orientation)
eulerhq.com has full pages for Reseller and Hyperscaler, and an AWS integration listed under Integrations. The help center has no article on either. A reseller program reuses features that are documented separately, and nobody says which ones. AWS Marketplace adds three capabilities with no setup page at all.
A reseller quotes, contracts and invoices the customer, which a referral partner never does. In EULER the reseller motion is assembled from features you may already use:
Reseller need
EULER feature
Set it up
Margin protection on a deal
A Deal Registration form, with an expiry window you set
A Reseller charge means the partner sent you the deal, so you owe the partner. Give resellers their own incentive structure: paying them like referral partners is a common mistake.
AWS Marketplace
EULER runs three AWS Marketplace capabilities next to the rest of your program:
Private offers built and sent from EULER, followed from changeset to active, without opening the AWS console.
ACE opportunity sync in both directions, so co-sell pipeline with AWS sits next to referrals and reseller deals.
Catalog sync, daily, so marketplace revenue reports with the rest of partner revenue.
Setup is not publicly documented
No public source says what connecting AWS requires on your side, such as which AWS Partner Central access or permissions. Do not start until your EULER contact confirms the list below.
Before you add either motion
Deal Registration form built and tested, with an expiry window that matches your program terms.
Reseller incentive structure separate from referral partners.
One owner for marketplace deals, so alliances and the partner team are not working the same opportunity twice.
For AWS: the access requirements confirmed with EULER before connecting.
What wrong looks like
WRONG - RESELLER ONBOARDING
Resellers added to the referral program, same form,
same incentive, "we'll split them out later".
Why it fails: a referral form gives no expiry, so a
reseller's claim on a deal has no defined end. The
referral incentive pays a referral rate on resale. And
every report built before the split mixes both motions.
Confirm with engineering
Connecting AWS needs [Partner Central role / IAM role / other]. Correct me with the list.
The AWS connection is set up at [location], by [self-serve / EULER team]. Correct me.
Reseller renewals are tracked at [object or page]. Correct me.
ACE opportunities synced into EULER attach to a partner by [rule]. Correct me.
Marketplaces other than AWS are [supported / planned / not supported]. Correct me.
eulerhq.com/solutions/reseller: registration by form, email or Slack; tiers, rebates, payouts; certification; renewals on the account.
eulerhq.com/solutions/hyperscaler and its FAQ: private offers changeset to active, bidirectional ACE sync, daily catalog sync. eulerhq.com/integrations: AWS under Hyperscaler.
Forms 2.0: Deal Registration form type. Submitting a Referral: registration expiry. MCP reference: Reseller charge direction.
A sample entry for the Change Log, written from changes the API Reference already announces but the Change Log never recorded. Above it: the format, so every future entry answers the same three questions for the reader. Did anything change for me? Do I have to act? By when?
Gap 11 of 13Reader Admins and developersType Release notes
The help center's Release notes link opens the Change Log, whose newest entry is dated 19 March 2026. Since then, EULER shipped or changed DealFlow AI, the EULER MCP connector, Forms 2.0 conditional logic and testing, Agreements V2 and API v1. Some of those changes need a customer to act, and the only place they are announced is inside the reference pages themselves.
The Change Log's one-line rows also say what changed, but not who is affected or what to do. That is fine for a fix. It fails for a change like the one below, where an integration's numbers move overnight.
The format
Title: what changed, in the reader's words.
Who it affects, in one line. "Everyone" is rarely true.
Action required: yes or no, first. If yes, what and by when.
Labels: New, Changed, Deprecated, Fixed, as in Keep a Changelog. A breaking change is labelled even when it is small.
Sample release notes start here
Referral list now includes older referrals
ChangedAffects: integrations that copy referrals from GET /v1/referrals. Action required: yes, if you keep an incremental copy.
An internal filter was leaving out referrals whose submission type had never been recorded, which hid many older referrals. They are now returned. For the same query you will see a larger total_count, and an incremental sync will receive a one-off batch of older referrals it has not seen. Nothing was deleted and no field changed. The list now counts the same referrals as total on GET /v1/analytics/referrals/funnel, so the two reconcile.
What to do: let your sync insert the older rows rather than treating them as errors, and expect partner-sourced counts built on this endpoint to rise.
Date: September 2026, as stated in the API Reference. Exact day: [from engineering].
Outbound forms now appear in the forms list
ChangedAffects: integrations that render GET /v1/referrals/forms. Action required: only if you show the list to users.
The endpoint used to return only the forms you receive referrals on. It now also returns the forms you use to send referrals to a partner (referral_type: "sent"), which were not discoverable before. To keep the old behavior, add ?referral_type=received.
You no longer need to send referral_type. EULER reads the direction from referral_form_id. The field is still accepted, so existing integrations keep working, but a value that contradicts the form now returns 422.
Date: [from engineering].
Optional email notification when you create a referral
Set send_email_notification to true to email the receiving company's team about a new inbound referral. It defaults to false, which is how the endpoint has always behaved. It must be a JSON boolean: the string "true" returns 422.
Date: [from engineering].
Sample release notes end here
What wrong looks like
WRONG - THE SAME CHANGE AS A CHANGE LOG ROW
| 9/xx/26 | API | Fixed referral list filter |
Why it fails: it reads as a fix nobody needs to act on.
A RevOps team whose partner-sourced count jumps overnight
will open a ticket, or worse, report the jump upward.
The entry has to say who is affected and what to expect.
Confirm with engineering
The four changes above shipped on [dates]. Correct me.
API changes go in the main Change Log, not a separate API changelog. Yes / no.
There is a changelog for the MCP connector at mcp.eulerapp.com/public/changelog that the help center should link to. Yes / no.
API Reference: GET /v1/referrals ("Changed September 2026" notice), GET /v1/referrals/forms (outbound forms now included), POST /v1/referrals (referral_type deprecated, send_email_notification).
Change Log: newest entry 19 Mar 2026. Help center article dates for MCP setup (15 Oct 2026) and Forms 2.0 (4 Sep 2026).
Short on purpose: the rules that prevent the inconsistencies found across the help center, each with the instance that prompted it. A style guide earns its keep by being checked against, so every rule here can be tested on a page in under a minute.
Gap 12 of 13Reader Anyone who writes help center, API or in-app textStatus Draft for product and engineering review
The job post asks for a style guide. The help center shows why: the same product name, partner tool and acronym are spelled differently from page to page. Each one is small. Together they make search miss pages and make the help center read as if no one owns it.
1. Names
Write
Not
Where it appears today
EULERCONFIRM
Euler
eulerhq.com, the help center header, the API and MCP references use EULER. Many articles and the Change Log use Euler. The nav lists both "Euler Pay Partner Guide" and "EULER Pay Fees Explained".
HubSpot
Hubspot
"Configure Hubspot for Partners" and "Hubspot Charges" sit beside "HubSpot Data Scopes in Euler".
Pipedrive
PipeDrive
eulerhq.com/integrations and the Reward page.
DealFlow AI
Deal Flow AI
The eulerhq.com footer.
PAM AI, POPS AI, then PAM, POPS
Pam, Pops
Consistent today. Keep it that way.
Market Development Fund (MDF)CONFIRM
Marketing Development Fund
Forms 2.0 and eulerhq.com say Market. The MCP reference says Marketing.
2. Titles
Task pages: verb plus object. "Approve a fund request", not "Fund Requests".
Concept and reference pages: a noun. "Referral statuses".
Sentence case for titles and headings.
No separators in titles. The MCP articles end in " l MCP", a lowercase L used as a divider, which screen readers read as the letter. Put the audience in the collection name instead: "MCP for customers".
3. The first screen of every page
One sentence on what the reader will have when they finish.
Who the page is for, and what they need first.
What can go wrong, before the steps, not after.
4. Procedures
One action per step, starting with a verb.
Every step ends with a Check: line saying what the reader should see.
UI labels in bold, exactly as the product shows them. If a label is wrong in the product, report it rather than correcting it in the docs. Example: Forms 2.0 quotes a tab called "Basic Informations".
Shall for what the procedure depends on. Should for a recommendation. Never swap them for variety. The convention comes from RFC 2119.
One labelled wrong example per page, with why it fails.
5. Page furniture
The "Still Have Questions?" block appears once, added by the template. It appears twice on Forms 2.0 and on the Slack Apps Product Guide.
Internal links use the current URL pattern (/en/c/...). Some articles still link to /en/articles/<number>-... addresses. CHECK THEY REDIRECT
Nav labels match page titles: the nav says "Release notes", the page says "Change Log". Pick one.
Every page shows an updated date. Release notes carry the date of the change, not of the edit.
6. Examples and data
Fictional companies only, on .example domains, which RFC 2606 reserves for documentation.
No real API keys, tokens or passwords, even fake-looking ones that match a real format.
Numbers in examples say they are examples.
7. Accuracy
A behavior is written only once someone has seen it, in the product or in a source. Otherwise it is a question for engineering.
Questions to engineering are statements answered yes, no, or correct me. No open-ended meetings.
When a feature changes, the pages that describe it change in the same release as the feature.
Check a page against this guide
Names match the table in section 1.
Title is a verb plus object, or a noun, in sentence case, with no separator.
First screen says result, reader and what can go wrong.
Every step ends with a Check.
One wrong example. Fictional data only.
Updated date shown, and every link resolves.
Confirm with product
The product name is written EULER in all documentation. Yes / no.
MDF stands for Market Development Fund. Yes / no / correct me.
"Release notes" and "Change Log" are the same page, and should share one name: [name]. Correct me.
Gap samples / Gap 13 - Internal playbook (docs, product, support)
Update the docs when a feature ships: internal runbook
An internal process guide, the kind the help center never shows customers. You finish it with every page that mentions a changed feature updated, a release note published, and support told what changed, in the same week the feature ships. It matters more at EULER than at most companies, because EULER's AI assistants read the help center too.
Gap 13 of 13Reader Technical writer, product manager, support leadType Internal runbook
Several help center pages describe EULER as it was, not as it is. The Change Log's newest entry is 19 March 2026. The API & Webhooks collection documents the workflow API while the API Reference documents API v1. DealFlow AI shipped with no article. None of these is a writing problem. Each is a missing step between "the feature shipped" and "the docs changed".
The cost is higher than a stale page. The EULER MCP connector includes a help tool that searches the public help center and returns article text to Claude, ChatGPT and other assistants. A stale article is now also a stale answer, delivered with confidence inside a customer's AI chat.
Sample documentation starts here
When to run it
A feature ships, changes behavior, or is renamed.
An API field, endpoint or error is added, changed or deprecated.
Support answers the same "how do I" question three times in a week. CONFIRM THRESHOLD WITH SUPPORT
What can go wrong
Updating the main article and missing the other pages that mention the feature: MCP prompt guides, Slack guides, Forms 2.0, the API Reference.
Publishing before the feature reaches every account. Beta features, such as API access, need the beta stated on the page.
Leaving the Change Log for later. Later is how it stopped in March.
Steps
Get the change in writing before release
From the engineer or PM, get: what changed, who it affects, whether anyone must act, and the release date. Ask as statements to confirm: "Starting [date], referral_type is optional. Yes / no / correct me."
Check: you can write the release note's "Affects" and "Action required" lines without guessing.
Find every page that mentions the feature
Search the help center for the feature name and its old name, then the API Reference and the MCP connector reference. Search the MCP prompt guides too: they often describe behavior in passing.
Check: a written list of pages, each marked update, unchanged, or retire.
Update the pages, and test what they describe
Run every changed procedure in a test workspace. Every step shall keep its Check line, and the check shall still be true.
Check: each page's updated date is this week, and you ran each procedure once.
Publish the release note the same day
Use the format in Release notes: title in the reader's words, who it affects, action required first.
Check: the Change Log's newest entry is this release.
Tell support and customer success
Post one message in the team channel: what changed, the links to the updated pages, and the question customers are likely to ask. Support should answer with a link, not a rewritten explanation.
Check: support can find the change from the links alone.
Ask the assistants
Through EULER MCP or PAM, ask the question a customer would ask about the feature. The answer should match the updated page.
Check: the assistant cites the updated article and repeats its current behavior. If it does not, find out when the help search index refreshes. CONFIRM INDEX REFRESH
Quarterly review
Once a quarter, sort the help center by updated date and review every page older than six months. CONFIRM INTERVAL Each one gets one of three outcomes: still true, updated, or retired with a redirect.
What wrong looks like
WRONG - RELEASE CHECKLIST
[x] API v1 live
[x] API Reference published
[ ] Help center
[ ] Change Log
Why it fails: the reference is right and the help center
is not, so a developer who starts in the help center
follows the older API. A release is not done until
every page that mentions it is done.
Confirm with engineering and product
Releases are announced internally in [channel], [days] before they ship. Correct me.
The MCP help tool searches the live help center, or an index refreshed every [interval]. Correct me.
The technical writer owns the Change Log. Yes / no / correct me.
Beta features are listed at [place], so docs can say which accounts have them. Correct me.