Workflows

An ISO 8601 timestamp is useful for ordering events and transmitting time with an explicit offset, such as 2026-10-01T12:00:00Z. It is not secret. Encoding or hashing a timestamp does not turn it into a secure token; predictable inputs can be guessed or replayed.

If a workflow needs an access token, generate an independent cryptographically random secret and give it an expiration and revocation path. If it needs to prove that a message was issued at a time, use a signed or MAC-protected structure that covers both the timestamp and the relevant payload. Validate timezones and clock skew, and avoid treating client-supplied time as authoritative without verification.

This workflow trims each line, converts text to lowercase, and removes duplicate lines in a directed pipeline. It is useful when a pasted list has inconsistent spacing or casing and you need a stable set of values.

Start with a safe sample such as Apple \nAPPLE\nPear. Decide whether output order should follow first appearance or be sorted; deduplication cannot make that choice for you. Check blank lines, Unicode letters, and values whose case is meaningful, such as product codes. Keep the original input so an unexpected normalization can be reviewed.

Before using it on real data, confirm each step's output and the behavior on empty or malformed input.

Use this workflow when you want a consistent list from messy text. It trims surrounding whitespace, lowercases each line, sorts the result, and removes duplicate entries. The sorting step changes original order, so choose this version only when order is not meaningful.

Try a synthetic example with mixed case, a repeated line, and an empty line. Compare the result with a handwritten expected list. Check whether locale-sensitive casing or Unicode normalization changes important names. Do not use it blindly for identifiers where ABC and abc refer to different things.

Save the original list until the cleaned output has been reviewed.

This workflow normalizes text and then calculates a SHA-256 digest. It can provide a repeatable fingerprint for non-sensitive sample text, but the normalization step means different original strings may intentionally produce the same digest.

Before relying on the output, document the exact normalization rules, character encoding, and line-ending behavior. Test the same input twice, a one-character change, and two inputs that differ only in whitespace or case. Compare a known sample with an independent SHA-256 implementation. A hash is not encryption and does not hide a short or guessable secret.

Keep the source text if you may later need to explain why two fingerprints match.

This workflow receives an event and sends a Slack notification. Before connecting a live source, define which events are allowed, authenticate the sender, and map only the fields the channel needs. A webhook endpoint exposed without validation can turn into a spam or data-leak path.

Test with a synthetic event and a private test channel. Check malformed payloads, missing fields, duplicate deliveries, Slack rate limits, and what happens when Slack is unavailable. Do not log webhook secrets or full sensitive payloads. Make retries idempotent or label repeated messages clearly.

A successful HTTP response from the webhook is not proof that the intended Slack message arrived.

This workflow minifies JSON and encodes it for transport in a URL. It is suitable only for small, non-sensitive payloads whose receiver expects that format. Minifying removes whitespace; URL encoding prevents reserved characters from changing the link's structure. Neither step encrypts the data.

Validate the JSON before encoding and decode a test URL at the destination to compare the exact data. Check size limits, Unicode, reserved characters, and whether the URL appears in browser history, logs, analytics, or referral headers. Never place tokens, private records, or passwords in the URL.

If the payload needs confidentiality, use an authenticated request body and suitable access controls instead.

This workflow reads an RSS feed and sends new entries to a Discord channel. Store a stable item identifier or canonical link so each poll can distinguish new entries from ones already delivered. Advance the checkpoint only after Discord accepts the message; otherwise a temporary failure can silently drop an item.

Normalize titles and links before posting, escape or disable mentions, and cap message length. Honour conditional feed requests when available and back off from rate limits. Test an unchanged feed, a corrected article, and a malformed item. A review path for bad entries is better than blocking all later updates or flooding the channel with duplicates.

For a password-generator workflow, draw random bytes from the operating system or browser’s cryptographically secure random API. Choose enough entropy for the purpose, then encode the bytes in a form the target service accepts. Base64url is a transport-safe representation of random bytes; it does not make predictable input secure.

Do not use Math.random, a timestamp, or a UUID as a substitute for a cryptographic random source. Display the new password once and avoid placing it in URLs, analytics, or routine logs. Respect the service’s length and character rules without introducing a predictable pattern. Test that generation fails clearly if a secure random source is unavailable, and never test with a real account secret in an unverified workflow.

A multi-hash workflow should state why each digest is produced. SHA-256 is suitable for routine file-integrity comparison when you trust the expected digest’s source. MD5 may be needed for legacy, non-security compatibility, but it must not be treated as collision-resistant proof of authenticity.

Hash the exact bytes, not a displayed filename or a text representation that may change encoding. Record the algorithm, source, and expected digest, then compare in a consistent format. For security-sensitive authenticity, use an authenticated signature or MAC with managed keys, not a bare hash alone. Test empty input, large files, and a known reference vector before using the result in a workflow.

This workflow sends one input down two branches: one Base64-encodes it and the other URL-encodes it, then merges the results. The two outputs solve different transport problems. Base64 represents bytes as text; URL encoding escapes characters that have special meaning in a URL component.

Test with ASCII, spaces, &, %, and non-ASCII characters. Confirm that both branches use the same original input and that the merge labels each result so they cannot be swapped. Decode each output independently and compare it with the source.

Neither encoding provides confidentiality or authenticity. Do not treat the merged output as a protected form of the original.

This workflow strips Markdown formatting, lowercases the remaining text, and builds a URL-friendly slug. It can help create a draft address from a heading, but the result needs review before publication.

Try headings with links, inline code, punctuation, accents, and non-Latin characters. Check what happens when formatting removal leaves an empty string or two headings produce the same slug. Avoid changing an already-published slug without a redirect, because existing links may break.

A slug is a public identifier, not just cleaned text. Keep enough distinctive words that readers and search tools can recognize the page.

This example applies Base64 encoding repeatedly through a loop node. It is useful for learning how the workflow carries output from one iteration into the next. It is not a security mechanism; multiple Base64 layers can still be decoded in reverse order.

Use a short, harmless input and a small explicit iteration count. Record the output after each pass, then decode the final result the same number of times to recover the source. Set a maximum iteration count and handle empty input or a failed step so the loop cannot run indefinitely.

For real workflows, ask whether repeated transformation has a purpose beyond demonstrating control flow.

This workflow decodes a JWT payload and formats it as JSON for inspection. It can help diagnose a synthetic token's visible claims, but decoding does not verify its signature, issuer, audience, expiration, or intended use.

Use fake tokens in shared examples. Never submit a live bearer token to a public forum or an untrusted workflow. Test malformed segments, missing claims, and invalid JSON so errors are clear rather than producing a misleading payload. If a system must trust the token, validation belongs in a separate step with the expected algorithm and key.

Treat the pretty-printed output as untrusted data until that validation succeeds.

A JSON-validation step should make branching explicit. Parse the input first; if it is not valid JSON, return a safe error with a location or reason and do not run downstream actions. If it parses, validate required fields and types against the workflow’s expected schema before routing it to the success branch.

Keep raw input and secrets out of ordinary logs. Test empty text, malformed syntax, a valid object missing a required field, and a valid accepted object. Define whether retries are safe and how duplicate submissions are recognized. A parser accepting the text proves only syntax, not that the payload means what the next step expects.

This workflow formats a JSON payload and checks whether it parses. That is a useful first gate for API examples and configuration files: malformed brackets, quotes, and commas should fail clearly.

Test valid JSON, empty input, a trailing comma, Unicode, nested objects, and a value with an unexpected type. A successful parse does not establish that required fields exist or that the application will accept the data. Add a schema or consumer-side validation step if those rules matter. Compare important values before and after formatting, including large numbers.

Use synthetic payloads if the source may contain private records or tokens.

A JSON validation workflow should separate syntax errors from schema or business-rule failures. Parse only within configured size and nesting limits, then validate required fields and types. Send successful structured data to the next step; pretty-printing is useful for people but should not replace the parsed object.

On failure, return a safe error code, JSON path when possible, and correlation ID. Do not echo a full payload that may contain secrets. Define what to do with duplicate keys and malformed Unicode so callers are not surprised by silent changes. Test an empty body, a deeply nested value, and a wrong field type before relying on the pipeline.

This template hashes text with SHA-256 three times in sequence. It demonstrates chaining nodes and inspecting intermediate output, but “three hashes” is not a general guarantee of enhanced security. For a simple integrity fingerprint, one modern hash of the intended bytes is usually the clearer design.

Test a public sample and record the digest after each pass. Make sure each node hashes the previous digest in the intended encoding—raw bytes and hexadecimal text produce different results. Check an empty input and a one-character change against an independent implementation.

Do not use this chain as a substitute for password hashing, encryption, or a keyed message authentication code.

This workflow forwards selected GitHub issue events to a Telegram chat. First verify the webhook signature against the original request body. Filter by repository and action so routine edits do not trigger alerts that nobody wants. Use the delivery ID to prevent a retry from sending the same notice twice.

Compose a short message with issue number, title, action, and a link. Escape Telegram markup and avoid forwarding the entire issue body: it may include private data. If Telegram is unavailable, retry with a limit and record a delivery failure for review. A test should cover both a valid issue event and a deliberately invalid signature.

This workflow checks input before hashing it and routes failures to an error output. Validate presence, type, and size first; only valid input should reach the hash step. Treat a bad input differently from a temporary dependency failure and from an unexpected internal error.

Use a structured error with a code, safe message, and correlation ID. Retry only operations known to be safe to repeat, with a bounded attempt count. Keep sensitive input and stack traces out of user-visible responses, while retaining enough private diagnostics to investigate. Test empty input, an oversized value, and a simulated downstream outage so each branch has a clear outcome.

This workflow parses CSV and appends rows to a Google Sheet. Before connecting a real sheet, define the expected columns, header behavior, field types, and how you will identify a row that has already been imported.

Test with a small synthetic CSV containing a quoted comma, a blank cell, and a repeated row. Check the result in the destination sheet, not only in the workflow log. Handle permission failures, timeouts, and partial writes: a retry after a timeout can otherwise append the same rows twice. Keep spreadsheet credentials out of logs and shared examples.

For production use, limit the workflow's access to the sheet it needs and record which input batch was processed.

CSV conversion needs explicit parsing rules. Decide the delimiter, encoding, header row, quoting behavior, and whether empty fields mean empty strings or nulls. Keep identifiers such as postal codes as strings so leading zeros survive. Reject duplicate headers rather than quietly overwriting a field.

Stream large files where possible and report input, accepted, and rejected row counts. For a bad row, keep its number and a safe reason in a separate output; do not shift columns or discard it silently. Validate the resulting objects against the expected schema before formatting JSON. Test quoted commas, embedded newlines, and a row with one missing column.

This workflow routes input to uppercase or lowercase processing based on a condition, then merges the chosen result. Define the condition in plain language: what exact input selects each branch, and what happens if the condition is missing or malformed?

Test one value for each branch plus an empty value. Confirm that only the intended output reaches the merge and that the branch label is visible if downstream steps need it. Unicode and locale-sensitive casing can change more than ASCII letters, so test representative text from the languages you support.

If a branch fails, the workflow should surface the error instead of quietly returning an empty merged result.

This template converts text into a URL-friendly slug. Use it to draft a short address from a post title, then remove filler words only if the subject remains clear. Keep names and terms that distinguish the post from others.

Test punctuation, accented characters, non-Latin text, and titles that normalize to the same string. A slug must be unique within the site. Once published, changing it can break bookmarks and search results; provide a redirect if a change is necessary. Do not put private information into a slug because URLs are widely logged and shared.

Review the generated result as a reader would see it in an address bar.

This workflow Base64-encodes text, URL-encodes that output, then hashes it with SHA-256. It is a demonstration of chained transforms, not a general-purpose “data security” pipeline. Encoding makes data transportable; hashing produces a fingerprint. Neither step encrypts the input.

Use a non-sensitive sample, record every intermediate value, and compare the final digest with an independent implementation. Specify whether SHA-256 receives URL-encoded characters as UTF-8 bytes or another representation. Test empty input and characters that require URL encoding. If the intended goal is integrity against an attacker, a plain hash is insufficient without a trusted comparison or keyed construction.

Keep the workflow's purpose and limitations visible to anyone reusing it.

An API key should be an unpredictable secret with a clear owner and purpose. Generate its secret portion from a cryptographically secure random source with at least 128 bits of entropy, then encode it in a transport-safe form such as unpadded Base64url. Do not derive it from a UUID, timestamp, username, or password.

Show the secret only when created. Store a one-way hash of the secret and a separate non-secret identifier for lookup. Give the key the narrowest useful scopes, an expiration or rotation policy, and a revocation path. Keep it out of URLs, browser bundles, ordinary logs, and analytics. Test both authorized and forbidden actions before relying on a new key. Treat accidental exposure as a reason to revoke and replace it, not merely to hide the old display.