What it does

A session template decides what an agent sees the moment a session opens: the anchor tab, any extra tabs, the session title, and whether the communication panel is docked, minimised or hidden. Application tab templates are the individual pages those tabs point at. Together they are the main lever you have over what "opening a case" actually means in the workspace app.

Key facts

• Session templates come in two types: Entity, bound to a specific user-owned table, and Generic, used for channel sessions. The type is set at creation and drives which other fields you get.
• Generic templates let you choose the anchor tab. Entity templates don't — the anchor is the record itself.
• Communication panel mode is Docked, Minimized or Hidden. For entity-routing sessions such as case sessions it defaults to hidden.
• Unique names follow <prefix>_<name>, where the prefix is 3 to 8 alphanumeric characters. Same rule for application tab templates and script steps.
• The session Title is shown to the agent at runtime and accepts slugs, so {customerName} or {anchor.ticketnumber} gives you a usable tab label instead of "Case".
• Out-of-the-box templates — Case entity session, Chat session, Voice call session, Entity records session, and the per-channel ones — cannot be customised. Clone the behaviour into a new template instead.
• Application tab template page types are Dashboard, Entity list, Entity record, Search, Third-party website, Web resource, Custom page and Control, each with its own parameter set.
• Parameters accept literals, slugs in the form {anchor.fieldname}, and OData expressions such as {$odata.contact.emailaddress1.?$filter=contactid eq '{anchor._customerid_value}'}.
• Entity record tabs can create as well as open: pass entityName plus a data JSON payload and the tab opens a pre-populated new record form.
• validateRecord on an Entity record tab controls whether the platform checks the record exists before opening. Left off, a bad id gives the agent an error page inside the session.
• Web resource and third-party website tabs reset to their initial state whenever the agent switches away and back.
• Session templates carry a Scripts tab where you attach agent scripts, with an expression builder (Enable build expression) to choose a default script conditionally at runtime.
• For routed work the session template has to be referenced from the workstream; configuring the template alone changes nothing.

When to use / skip

Everyone gets the out-of-the-box templates whether they want them or not, so the question is whether to build custom ones. Do it when the anchor form alone leaves agents hunting — a second tab holding the customer's other open cases, or an external system view, genuinely cuts handling time. Skip the elaborate four-tab session design that looks impressive in a workshop; agents ignore tabs they didn't open themselves, and every auto-opened tab costs load time on session start. Two tabs is a good default, three is the practical maximum before it feels cluttered.

Configuration decisions

• Entity or Generic per template, and which tables get their own entity session template at all.
• What the session title shows. Ticket number and customer name beat record name in almost every case, because the tab is narrow.
• Which extra tabs open automatically versus which are left for a macro or a command to open on demand.
• Communication panel mode per template — docked is right for voice, hidden for pure case work.
• Whether tab parameters resolve through slugs or OData. OData is more powerful and noticeably slower on session start.
• Which script, if any, is the default for the template, and whether that needs the expression builder or a single fixed assignment.

Gotchas

• Editing an out-of-the-box template appears to work in the form and then doesn't apply. Always clone.
• Unique name prefixes are validated on save; a prefix outside 3 to 8 characters fails with a message that doesn't name the field clearly.
• OData parameters that return nothing produce an empty or errored tab rather than skipping it, so agents see broken tabs when the lookup is blank — very common with unqualified conversations that have no linked contact.
• Slugs are resolved against the anchor record. Referencing a field the anchor form doesn't include still works, but referencing one the agent has no read privilege on doesn't, and the failure is silent.
• Session templates for routed work only take effect through the workstream. Changing the template without republishing the workstream configuration is the classic "why is it still opening the default" ticket.
• Every auto-opened tab is a page load on session start. Four tabs on a slow tenant turns accepting a chat into a five-second wait, which agents will blame on the phone system.

Consultant notes

• Prototype the tab set with real agents watching, in a session, on their actual screen size. Tab design decided in a Teams call is always wrong.
• Keep a naming convention across templates, tabs and scripts using one prefix for the client. When you're debugging a session that opened the wrong thing, half the job is finding which record you're looking at.
• Tell the client that out-of-the-box templates are locked before they spend a workshop editing one.
• Check the unqualified or anonymous customer path explicitly. It's where slug-driven tabs fall over.
• Before go-live, time session start with the full template applied. If it's over a couple of seconds, drop a tab.

---

Worth revisiting if Microsoft adds runtime control over anchor tabs, or extends the page types available to application tab templates.