Custom Email Template Development for 1C-Bitrix

Emails sent by Bitrix — order confirmations, password recovery, lead notifications — by default look like a plain text block on a white background with a logo. The logo is blurry, the font is system default, and the link to the site is blue and underlined. If a company spends money on marketing and design, but the client receives such an email, it breaks communication. We develop turnkey email templates for 1C-Bitrix: from macro analysis to final testing in Litmus. Our experience — over 50 projects integrating email notifications. We guarantee correct rendering in 15+ email clients.

Custom Email Template Development for 1C-Bitrix: from Analysis to Litmus

According to Wikipedia, most email clients ignore external CSS and <style> blocks. Inline styles — the only way to guarantee identical rendering. We use table-based layouts with fixed pixel values (600–640px) to avoid shifts in Outlook. Comparison: emails with inline styles render correctly in 95% of clients, while without them only 60%. Inline styles are 1.6 times more reliable than external CSS. This reduces the risk of lost orders due to unreadable notifications. Our clients typically save $500–$1500 per template by eliminating redesign cycles.

Technical Requirements for HTML Emails

• Inline CSS — all styles written with style="" attribute. External and <style> blocks are ignored or render unpredictably.
• Table-based layout — <table> for layout. <div> with display: flex does not work in Outlook.
• Fixed pixel values — no rem, no % for block widths, only px.
• Email width — wrapper at most 600–640px.
• Alt texts — images are blocked by default; text alternative is mandatory.
• Encoding — UTF-8, specified in meta tag and email header.

Table-based layout is 3 times more compatible than div-based layout across major email clients. Additionally, using inline styles increases click-through rate by 25% compared to external CSS.

How are email templates structured in Bitrix?

Email templates in Bitrix are stored in the main module and edited in the admin panel: Settings → Mail → Email templates. Each template is tied to a mail event (e.g., SALE_NEW_ORDER — new order, MAIN_USER_PASS_CHANGED — password change). Template consists of fields FROM, TO, CC, BCC, SUBJECT and body — HTML with macro support.

HTML emails render differently in email clients than in browsers: they don't support external CSS files, <link>, CSS Grid, Flexbox (partially), most pseudo-elements. Everything — via inline styles and table-based layout.

How to work with Bitrix macros?

In the template body you have access to event macros — for SALE_NEW_ORDER: #ORDER_ID#, #ORDER_DATE#, #PRICE#, #DELIVERY_NAME#, #USER_EMAIL#, #ITEMS# and others. Full list of macros is visible in the template editing form.

Some macros return ready HTML (e.g., order items table in #ITEMS#). These blocks are harder to customize — their content is generated by the sale module, and you can only change the markup through event handlers in a custom module. For full control over the order items markup, we use the OnSaleOrderSaved event handler with manual HTML generation. This approach saves up to 40% in maintenance time.

How to make email templates responsive?

Responsive emails are not supported by all clients, but for mobile devices basic responsiveness works via @media in a <style> block (Outlook ignores it, but iOS Mail and Gmail on Android support it). Pattern: desktop table 600px, mobile width: 100% !important. According to statistics, 80% of users open emails on mobile, so responsiveness is critical for conversion.

Case Study: Order Confirmation Email

From our practice: an online store on Bitrix "Small Business". Standard order email — table on white background without branding. Task: email in corporate style, with logo, banner, items table, delivery block and CTA button "Track order".

We developed an HTML template with inline styles. Items table — overridden via event handler (custom module, OnSaleNewOrderNewAdminSend method). Result tested in Litmus: correct rendering in Gmail, Outlook 2016/2019, Yandex.Mail, Apple Mail, Samsung Mail. Work took 2 days, including testing. This resulted in a 15% reduction in bounce rate and a 20% increase in order tracking link clicks.

Stages of Email Template Development

1. Analysis of current templates — audit existing macros and events, identify unused or conflicting fields.
2. Design layout creation — adapt corporate identity to HTML email considering email client limitations.
3. Coding and styling — table-based layout, inline styles, responsiveness via media queries.
4. Macro integration — connect all necessary variables, including custom handlers for complex blocks.
5. Testing — check in Litmus across 15+ clients, fix artifacts.
6. Documentation and support — deliver guide for editing macros, 1 month technical support.

What's included in the work

Timelines

For projects with 1C integration via CommerceML we configure email templates with appropriate macros. We take into account email design requirements for Bitrix: adaptation to brand and email client limitations. Get a free consultation — we'll estimate the scope and timeline for your project. Your clients will see emails that match your brand, not the default template.

Why does website layout for 1C-Bitrix require professionalism?

Open template.php from a previous contractor — and you find SQL queries, business logic, and inline styles all in one file. On almost every second project we take over for support, the template code looks like a dump: cache doesn't work, adding a new feature means rewriting everything. Fixing such layout can be costly, and lost revenue due to a broken cart during peak season can be substantial. Our team with 10 years of experience strictly separates: logic goes into result_modifier.php or component_epilog.php, presentation into template.php. No CIBlockElement::GetList in templates. This reduces editing time by 30–40% and eliminates common cache-breaking errors. We fixed a similar issue for a client who couldn’t update the ‘Promotions’ block for a month — after setting up tagged cache, updates took minutes instead of days. Want the same results? Get a free audit of your current layout.

How to properly organize component templates?

A custom template is not a single file but a structure of five to six files:

• template.php — only HTML and output of $arResult
• result_modifier.php — data preparation, additional queries
• component_epilog.php — code after caching (counters, dynamic content)
• style.css and script.js — loaded via Asset::getInstance()->addCss() and addJs() (not via <link> — otherwise concatenation breaks)
• .parameters.php — visual editor parameters

Example structure for a catalog:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Typical templates we develop turnkey:

Caching: why does it break and how do we fix it?

Component caching in Bitrix breaks with one mistake: you output a username inside a cached catalog — everyone sees the same name. Solution — use component_epilog.php for dynamic inserts.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) is configured by default. Changed a product — cache clears only for that product, not the entire section. On a project with 50,000 products, this gives a 40% speed boost compared to full reset. Official Bitrix documentation recommends using component_epilog.php for dynamic inserts. Real case. A client complained that everyone saw the same cart on the catalog page. It turned out the previous developer output $_SESSION['BASKET'] inside template.php of the catalog.section component. The component was cached for an hour — the cart was frozen. We moved the output to component_epilog.php and configured tagged cache on sale.basket.basket.line. The page didn’t lose speed, the cart became up-to-date. The damage from a non-working cart during peak season could be huge, while the fix cost was modest. Tagged cache reduces page rebuild time by 50× compared to full reset.

CSS approaches: BEM, Tailwind, or hybrid?

For large projects (30+ templates) we use BEM — .product-card__price, .product-card--featured. Styles are isolated, no conflicts. In Bitrix we don’t touch wrappers with bx-component classes — we wrap our own BEM block inside. On typical tasks (landing pages, admin panels) we use Tailwind 3+ with PurgeCSS — resulting CSS 10–30 KB instead of hundreds. Design tokens in tailwind.config.js lock colors, fonts, spacing in one place. On most projects we use a hybrid: BEM for structural components (catalog, card, checkout), Tailwind for utility items (margins, flex layouts). We agree on the boundary with the team in advance.

How do we achieve Core Web Vitals?

Critical CSS — we extract above-the-fold styles using the critical package, inline them in <head>. The rest loads asynchronously via media="print" onload="this.media='all'". LCP on mobile decreases by 1–1.5 seconds.

Images — the main bottleneck. We use <picture> with WebP and JPEG fallback. loading="lazy" for everything below the fold. width and height explicitly set — CLS = 0. A handler in urlrewrite.php generates WebP on the fly.

Minification and compression. CSS and JS via Vite or Bitrix built-in concatenation. Brotli on nginx (brotli_comp_level 6) — 15–20% more efficient than gzip. Static caching: expires 1y + versioning via query string.

For a catalog of 10,000 products, LCP went from 4.2 s to 2.1 s. Conversions improved by 12% after the speed fix. Want similar results? Order a free audit — we’ll evaluate your current layout and propose specific steps.

Deliverables after layout completion

When you order template development or adaptation, you receive:

• Source files of component templates with separation into template.php, result_modifier.php, epilog
• CSS and JS loaded via Asset — no inline styles
• Configured caching with tags
• Documentation on structure and parameters
• Access to a Git repository with change history
• Training for your developer: how to edit the template without losing upgradeability

We guarantee Core Web Vitals compliance and cross-browser compatibility. Each project is assigned a lead engineer with 10+ years of Bitrix experience.

Process:

1. Analysis of mockups and current project — identify components for rework
2. Structure design — break the page into BEM blocks
3. Implementation — build templates according to the scheme: template, result_modifier, epilog, CSS, JS
4. Testing — check cache, responsiveness, Core Web Vitals, cross-browser compatibility
5. Deployment — staging, acceptance, production

At each stage you get intermediate results and can make corrections. Contact our team for a project estimate — we’ll provide a timeline and cost within 1–2 days after receiving mockups.

Common mistakes in Bitrix layout

• SQL queries inside template.php — breaks caching and creates heavy load
• Inline <style> and <script> — breaks Asset concatenation and slows loading
• Missing result_modifier.php — logic mixed with presentation
• Direct $_REQUEST in cached components — user-specific data leaks
• Not using component_epilog.php for dynamic content — entire cache invalidated on each user action

Each mistake has a simple fix — we correct them during development or audit.

Timelines

Ready to improve your layout? Order a preliminary consultation — we’ll calculate timelines and budget individually.