Time Entry is an entry processor that starts a pipeline based on time.

It supports common scheduling styles:

• simple intervals (e.g., every 15 minutes)
• cron expressions (e.g., “every weekday at 08:00”)
• time zones (because commerce does not run on UTC feelings)

If you’ve been building scheduled integrations for years, you already know why this matters:

• fewer external schedulers
• fewer scattered jobs across servers
• schedules live with the pipeline definition
• everything is trackable and observable in one place

{
  "id": "time_entry",
  "type": "Qilin.TimeEntry",
  "config": {
    "scheduleType": "Cronjob",
    "cronExpression": "0 */15 * ? * *",
    "timeZone": "Europe/Berlin"
  }
}

That’s “every 15 minutes” in a predictable time zone.

No separate infrastructure. No mystery scheduler running on an old VM “because it always worked”.

The Email Processor does what it says:

• sends email to one or more recipients
• supports To / CC / BCC
• allows dynamic values from pipeline execution context
• supports templates via Scriban (so emails can be personalized and structured)
• uses stored credentials (so you don’t paste SMTP passwords into configs)

This becomes useful immediately for:

• failure alerts
• daily/weekly summaries
• “import finished” notifications
• “data quality issue detected” reports
• agency handover and operational transparency

A simplified config:

{
  "EmailProviderName": "CustomSmtpProvider",
  "credentialId": "credential-guid",
  "Receivers": { "raw": ["op*@*********ny.com"] },
  "From": { "raw": "qi**********@*********ny.com" },
  "Subject": "Qilin pipeline alert",
  "BodyContent": "Pipeline {{ FlowObjectAttributes.entry.pipelineId }} reported {{ FlowObjectAttributes.entry.status }}",
  "IsBodyHtml": false
}

You can also use templating to include richer context:

• object IDs
• execution IDs
• counts (how many items processed / failed)
• links to tracking pages

A scheduled pipeline without notifications is a silent machine.

A notification system without scheduling becomes reactive chaos.

Together, they enable a very traditional – but very effective – operational pattern:

1. run predictable jobs on predictable rhythms
2. surface exceptions immediately
3. let humans focus on decisions, not polling dashboards

• scheduling lives with the pipeline definition
• templates are versionable, testable, and dynamic
• credentials are managed centrally and permissioned
• fewer “sidecar services” just to send emails or run cron

• Merchants: get operational transparency without extra tooling
• Agencies: deliver “managed integrations” with built-in reporting and alerts
• Investors: these are features that reduce support cost and increase platform stickiness

In October we’ll tackle a very modern problem with a very classic pattern:

moving large binary data through pipelines without moving it through pipelines.

(Yes, that sentence is weird. It will make sense.)

Some of the best engineering work is turning “how we always did it” into platform primitives.

Time Entry and Email are exactly that: practical tools for real operations, baked into Qilin.Cloud.

Yes, power users can define anything as code.

But commerce integrations are rarely built by a single person. They’re built by:

• platform developers
• solution engineers
• agencies
• merchants’ internal teams

When the interface for building pipelines is too raw, three things happen:

1. onboarding slows down
2. mistakes increase
3. tribal knowledge becomes the only “documentation”

So we’re building a pipeline builder that still respects engineers – but doesn’t punish everyone else.

The Portal UI now supports the core workflow you expect:

• create and manage pipelines and connectors
• build flows step by step
• view pipeline definitions (yes, including the underlying JSON when you want it)
• validate configuration early instead of failing late

The goal is classic engineering wisdom:

> Make the right path the easy path.

The other half of pipeline design is observability.

When something goes wrong, you shouldn’t need to:

• grep logs across services
• reconstruct a timeline from screenshots
• guess which processor failed

So the Portal UI has been expanding the Data Tracking experience, making it easier to:

• inspect executions
• understand which step produced which output
• trace what went into a connector call
• spot where and why a branch stopped

This is the kind of thing mature operations teams demand – and the kind of thing agencies love, because it saves time on support.

A classic commerce pain: invalid offers and incomplete product data that only get noticed after the destination rejects them.

We’ve been improving validation workflows so pipelines can detect and surface problems earlier—when it’s cheaper to fix.

It’s not glamorous, but it’s the difference between:

• “we’ll fix it next sprint”
• and “we shipped broken prices to the marketplace”

One of those is expensive.

Authentication is another place where old-school integrations get messy:

• credentials sprinkled across systems
• different auth types per connector
• unclear ownership between agencies and merchants

We’re tightening the portal-driven configuration story so connector authentication becomes:

• explicit
• manageable
• reusable

…and less likely to turn into “please DM me the production token” (which should never be a sentence).

Developers

• faster iteration while still being able to inspect the underlying definition
• less time spent debugging “what is this pipeline even doing?”
• better separation between pipeline logic and credential management

Merchants

• clearer visibility into what’s running and why
• earlier detection of invalid data
• fewer surprises at the channel edge

Agencies

• more repeatable delivery
• less support load
• easier handover when a project transitions from “implementation” to “operations”

Investors

Pipeline UX + observability is platform leverage: it reduces cost of customer success while enabling more integrations per team.

In February, we’ll go back to a classic commerce question:

How fast should this pipeline run?

Not “as fast as possible”—but as fast as makes sense for:

• cost
• stability
• connector limitations
• business needs

We’re bringing more control to processing speed at the pipeline level.

Good integrations are like good infrastructure: they’re calm, boring, and dependable.

The Portal UI work is about making that calm easier to achieve.

Qilin.Cloud is building the tools so your pipelines don’t become archaeological artifacts.