Skip to main content
Cookbook · Personalization

Add a deep-link action to the planning board

Developer ~15 min

Surface a button in the planning board context menu that opens an external URL - a CRM record, an internal tool, anything. Pass appointment fields through as query parameters.

Before you start​

The loop this closes: a planner spots that an appointment needs a follow-up, switches to another system, retypes the customer's details, then comes back. An action URI collapses that into one click, carrying the record's data with it so the destination already knows what to open or prefill.

Decide which verb you need first, because it changes the shape of everything else:

  • GET is the workhorse. Most back-office systems expose deep-link URLs that open a specific record, and Dime.Scheduler opens the resulting URL in a new tab.
  • POST is for pushing a structured payload, typically into a workflow engine expecting an inbound webhook.

If you are deep-linking into a record, you want GET.

1. Know what scopes an action to a record​

Two things decide whether an action appears on a given record, and both are common sources of "my action doesn't show up":

  • The entity type. Planned task, unplanned task, map pin, new appointment. An action declared for the open task list never appears on the planning board, and the reverse is equally true.
  • The source app and source type of the job behind the record. This is what stops a tenant connected to several back offices from showing a dozen irrelevant menu items on every record.

The available placeholders depend on the entity type you bind to, so this choice comes before you write the URL.

2. Build the URL​

Find the URL that opens the record in the target system, then substitute placeholders where the record-specific values go. Business Central, for instance, documents its web-client URL format, and most systems have an equivalent.

Which placeholders you can use depends on the entity type you bound the action to in step 1, so check the list for your entity type rather than assuming they are shared. Actions has the full set per entity type.

3. Write the description carefully​

The description column is the entire user experience of this feature. It is the only thing a planner ever sees.

Keep it short and verb-led: "Create absence", "Open in BC", "Email customer". A description like "BC Integration Action 2" is a feature nobody uses.

4. Test from the context menu​

Right-click the record in the planning board context menu and confirm the item appears and resolves.

The map works differently and is worth testing separately if you use it. Select the pin or pins, then click the anchor icon to get the list of available actions. Because you can select several pins at once, one action can cover every selected task, which is how you drive back-office logic over a batch.

One constraint on that: multi-item actions are only offered when all selected items share the same source app and source type. A mixed selection silently offers nothing, which looks like a broken action rather than a rule.

Verify​

Trigger it on a real record and confirm the target system opens the right record, not just any page. A placeholder that fails to resolve usually lands you on a generic landing page rather than throwing an error, so a successful-looking click is not proof.

Then check an entity type you did not bind, and a record from a different source app, and confirm the action is absent from both.

Last updated on by Hendrik Bulens