Create Shortcuts

Creating shortcuts is the most common action in Lora and the fastest way to turn long, messy links into something simple and memorable.

Overview

Every shortcut belongs to a single workspace. Within that workspace, it must have a unique slug, a destination URL, a folder, and a visibility setting. These four fields are required. Everything else, such as dynamic parameters, dynamic routing, or comments, is optional.

How to create a shortcut

There are three ways to start creating a shortcut. You can press C on your keyboard to open the creation modal from anywhere in the app. You can click the Create Shortcut button in the upper left corner of the workspace. Or you can go directly to https://app.uselora.com/new in your browser; if you are logged into Lora, you’ll be redirected to the creation page.

Once the creation form is open, enter a slug (for example /handbook), paste the destination URL (such as https://confluence.acme.com/hr/handbook), select a folder (for instance HR), and choose a visibility option. After saving, your shortcut is live immediately.

Destination URLs and HTTPS

You can paste a full URL or just type a hostname. If you leave off the scheme, Lora adds https:// for you, so confluence.acme.com/hr/handbook becomes https://confluence.acme.com/hr/handbook. HTTPS is the default: if you paste an http:// link, Lora upgrades it to https:// so visitors reach the destination over an encrypted connection. Links that already use https://, or another scheme like an app deep link, are kept as you typed them.

Keeping an HTTP-only destination (not recommended)

A few legacy systems are only reachable over plain, unencrypted http://, which the automatic upgrade to https:// would break. To keep HTTP, prefix the destination with an exclamation mark:

!http://legacy.internal.acme.com/report

Lora strips the leading ! before saving and skips the upgrade, so the shortcut points at http://legacy.internal.acme.com/report. The creation form then marks the http:// destination as an insecure redirect target.

We don’t recommend this. Traffic to an http:// address isn’t encrypted, so anyone on the network path can read or change it. Browsers also warn visitors that the page is not secure. Use it only when a site has no HTTPS, and drop the ! so the destination upgrades to https:// as soon as one is available.

Visibility

Visibility is a required setting for every shortcut. You must decide who can access it before it can be created. Opening any shortcut requires being signed in to its workspace; visibility narrows things from there.

Free supports Workspace visibility only. Private and Unlisted are available on Basic, Business, and Enterprise.

• Workspace makes the shortcut available to everyone in the workspace.
• Unlisted keeps the shortcut out of the workspace overview and search — only the shortcut owner sees it listed. Anyone in the workspace who has the link can still open it.
• Private keeps the shortcut visible only to you.

This ensures that every shortcut has a clear access policy from the moment it is created.

QR codes

Every shortcut in Lora automatically generates a QR code when it is created. You don’t need to configure anything - the QR code is ready to use right away.

You can download the code from the shortcut details page and place it wherever your team needs fast offline access, such as posters, office doors, or training materials. Scanning a code resolves the shortcut exactly as clicking the link would: the scanner has to be signed in to the workspace, and the shortcut’s visibility rules still apply.

Optional shortcut features

Beyond the required fields, the creation dialog includes advanced features you can enable when needed.

Dynamic shortcuts

Dynamic shortcuts use placeholders in the destination URL. Instead of a fixed link, the destination becomes a template that fills in values when the shortcut is opened.

Placeholder syntax

There are two formats, both equivalent:

• Simple: {ticket}. Fastest to type for one-parameter shortcuts. Supports the | raw modifier ({path | raw}).
• Standard: {argument name="ticket"}. Required to set a default value (default="..."). Also supports | raw ({argument name="ticket" | raw}).

{ticket} and {argument name="ticket"} behave the same way. You can mix both styles in one URL. Lora stores the destination exactly as you typed it.

Placeholder names start with a letter and contain letters, digits, hyphens, or underscores (1–50 characters, no spaces). Add an optional label for display text with spaces: {argument name="issueID" label="Issue ID"}. The name is the query parameter — matched exactly, capitalization included — while the label only changes what visitors read on the prompt. Use the same name in multiple spots when you want a value reused. Lora only asks once.

Default values

A default fills in when the visitor doesn’t supply a value, so the link still works without a prompt.

https://example.com/{argument name="lang" default="en"}

• /lang → https://example.com/en (default kicks in).
• /lang/fr → https://example.com/fr (visitor’s value wins over the default).

Defaults only work in the standard format.

Raw mode (no URL encoding)

By default, Lora URL-encodes every value, so react hooks becomes react%20hooks in the destination. If you actually need raw characters in the URL, like a path segment that already contains slashes, append | raw:

https://example.com/{argument name="path" | raw}

Use it sparingly. Raw values can change what the resulting URL means.

How visitors supply values

Lora reads placeholder values from two places, in this order:

1. Path segments after the slug (positional). For /jira/{ticket}, opening /jira/ABC-123 sets ticket = ABC-123. With multiple placeholders, segments map to them in declaration order.
2. Query string (by name, matched exactly). For /search?query=react, the query parameter overrides any positional value with the same name. Capitalization has to match — ?Query= is a different key than {query} and is ignored. If a key appears more than once, the last value wins.

If a required placeholder is missing, Lora shows a small prompt page with one input per placeholder. Submitting redirects through the same URL. Defaults appear as the input’s hint text.

Examples

Single placeholder (simple form):

Slug	/jira
Destination	https://jira.acme.com/browse/{ticket}
Usage	/jira/ABC-123 → opens Jira ticket ABC-123

Multiple placeholders (standard form):

Slug	/gh
Destination	https://github.com/{argument name="org"}/{argument name="repo"}
Usage	/gh/acme/web-app → opens the acme/web-app repository

Optional value with a default:

Slug	/lang
Destination	https://example.com/{argument name="lang" default="en"}
Usage	/lang → English; /lang/fr → French

Query string override:

Slug	/search
Destination	https://acme.com/search?q={argument name="query"}
Usage	/search?query=react+hooks → searches for “react hooks”

When to use dynamic shortcuts

Dynamic shortcuts work well for tools your team uses with changing parameters: issue trackers, search, documentation sites, dashboards with filters, or any URL that follows a fixed pattern.

A shortcut with a fixed destination returns a 404 on a non-empty path tail. /handbook/extra on a static /handbook is almost always a typo, so Lora doesn’t silently drop the extra segment.

Dynamic routing

Dynamic routing sends different visitors to different destinations from one shortcut. Each rule pairs one or two conditions about the visitor with the destination they should get, so a single slug can serve every region and platform you care about.

Dynamic routing is available on the Business plan and above.

How rules are evaluated

The rules on a shortcut form an ordered list. Lora reads them top to bottom, uses the first rule whose conditions all match, and stops there. Order is how you express priority, so put your most specific rule first.

Two conditions in the same rule both have to match. Several values inside one condition mean “any of these”, so a single Country condition can list Austria, Germany, and Switzerland at once. Every condition uses either is or is not; is not matches every visitor whose attribute is not one of the values you picked. Because a rule holds at most one condition per attribute, it never gets more complicated than “Country … and Platform …”. A shortcut can hold up to 10 rules.

If no rule matches, the visitor goes to the shortcut’s normal destination URL. That destination is always the fallback, so you never need a catch-all rule.

Two attributes are available: Country and Platform. Platform covers iOS and Android phones only. Anything Lora can’t classify as one of those two, including desktop computers, tablets, TVs, and bots, never satisfies an is condition and always satisfies an is not condition. The same holds for a visitor whose country Lora can’t determine. Desktop visitors therefore get the default destination unless a rule deliberately includes them.

How to set up dynamic routing

1. Open the shortcut creation or edit page.
2. In the Dynamic routing section, click Add rule.
3. Pick an attribute (Country or Platform), choose is or is not, and select one or more values.
4. Optionally add a second condition to the same rule to narrow it further.
5. Under Then go to, enter the destination URL for that rule.
6. Add further rules in the order you want them evaluated, most specific first.

Example

A single /app shortcut with two rules:

Rule	Conditions	Then go to
1	Country is Germany and Platform is iOS	https://apps.apple.com/de/app/acme/id123
2	Country is Spain	https://acme.com/es/descargar
Default	No rule matched	https://acme.com/download

An iPhone in Germany matches rule 1 and lands in the German App Store. Any visitor in Spain matches rule 2, phone or not. A German Android phone matches neither rule and gets the default destination, and so does a laptop in Berlin. If you want a separate Android destination, add a rule for it.

When to use dynamic routing

Localized content is the common case: careers pages, support portals, anything that has a per-country version. Download links that should open the right store are the other one. It also helps when a campaign needs a single slug to serve several audiences, since you don’t have to mint a separate shortcut per variant.

Masked URLs

Masked URLs are available on Business and Enterprise. They keep the original destination out of the browser bar by displaying the destination inside a Lora page. Masking is a presentation feature, not an access-control or secrecy boundary; visibility and destination permissions still apply.

Masking requires technical prerequisites. The destination site must allow embedding inside an iframe. If the target website blocks embedding with headers such as X-Frame-Options or Content-Security-Policy, masking will not work. In those cases, the shortcut will behave like a normal redirect.

Expiration

Expiration is available on the Business and Enterprise plans. Set a date and time after which visitors see Lora’s shared expired-link page instead of the destination.

On the shortcut creation or edit page, enable Expire this shortcut, pick a date and time, and save. Clear the date or turn the setting off to remove an expiration.

Expired shortcuts stay reachable by slug or short/ link — visitors see the expired page, not a 404. Expiration is not the same as archiving; use Show archived for archived shortcuts.

Expired shortcuts are hidden from the workspace overview, search, and the Lora extension by default. To find one for reactivation or editing:

1. From your workspace, open the overview.
2. Click Display options.
3. Turn on Show expired.

With Show expired on:

• Workspace Owners, Admins, and Moderators see every expired shortcut they can access.
• Other members see only expired shortcuts they own.

The edit page shows a notice when a shortcut is expired and who can reveal it in the overview.

Note: Setting or changing an expiration date requires Business or Enterprise. After a downgrade, existing expiration dates stay enforced until you remove them on a plan that allows editing.

Comments

Shortcuts can include comments for context or internal notes. For example: “This link is for internal HR use only. Updated quarterly.” Comments appear in the shortcut details page but are not visible to end users.

Edit Shortcuts

Shortcuts can be updated at any time. To make changes, open the shortcut’s details/edit page. From there, you can directly update the slug, destination URL, folder, visibility, tags, and advanced settings such as geo-targeting, device targeting, masked URLs, and comments. Once you save, the shortcut is updated immediately, and the changes are live for all users who have access to it.

How to open the edit page

There are two ways to open the edit page of a shortcut:

1. Use the three-dots menu next to the shortcut and select Edit.
2. Append + to the shortcut slug in your browser’s address bar.

For example:

• Entering short/handbook+ opens the details/edit page for the handbook shortcut.
• Entering /acme/short/jira+ opens the details/edit page for the jira shortcut in the acme workspace.

The + suffix works on any shortcut redirect URL (/short/…, /s/…, or workspace-scoped /<workspace>/short/…).