Docs / Development / Action


Most of the operations done on Content in sensenet is governed via Actions. An Action is basically a command, instructing the system to use a specific component, a so-called Application, to display or modify the Content item addressed. To read more on the mechanisms and structure of Applications, see the page on the Smart Application Model.

Prerequisites: some of the features described in this article (about displaying content using Pages) are available only if you have the sensenet WebPages component installed, but the underlying philosophy of arranging applications, security and url generation applies even if you only have the core Services layer.

There are several kinds of actions in sensenet: there are HTML actions that lead the user to an actual page (e.g. the Edit page of a content, where you can modify its properties); there are client-side actions that do something in JavaScript (e.g. display a popup dialog for picking a content); there are service actions that do something with the content and redirect you to a different page; and there are the OData actions that make the foundation of the REST API in sensenet.

In this article we go through these action types and look at their common use cases.

The Smart Application Model makes it possible to address Content with links pointing to them using their paths in the Content Repository. An ?action parameter can be used to select the application to handle the Content - in other words this parameter defines what to do with the Content. For example:

If a content item is requested without an action, it is equivalent to specifying the default action, which is Browse. Actions are more often referred to as the links that guide the user to the requested application page. An Action link is presented with an ActionLinkButton control that is a simple HTML link also displaying the requested Application’s link.

From version 6.3 sensenet provides a Client-side action framework for displaying actions in Javascript.

Actions and Applications

Actions are basically unlimited in number, builders can create Applications for specific, custom actions that the business scenario calls for. Available Actions on a Content are projections of defined applications for its Content Type. It’s not trivial to tell what Actions are valid for a specific Content item, as one needs to take into account all Applications defined for the Content Type of the item, as well as current user privileges on each of those and the item itself. The provided tools (ASP.NET controls available in the WebPages component) for displaying Actions natively handle the problem of available Actions:

If you do not have the WebPages component installed, our action framework still helps you constructing action links, so you do not have to assemble links manually.

JavaScript and service actions

Some action links do not navigate the current page to an application defined for the specified Content, but rather process data in the background and return or navigate to a custom page. An action link can run custom JavaScript code on the client side. A good example for this is the Copy selected… action link that when initialized from a list in Content Explorer it pops up a Content Picker where the destination folder can be selected, and the actual copy operation only takes place after the destination has been selected.

The type of rendered Action is controlled by the application it refers to. The Application’s ActionTypeName property defines the type (.Net class) of action to be rendered.

OData actions

The REST API of sensenet is built on OData actions, and you can create your own custom ones too to extend this API.

Action classes and methods

In most cases it is sufficient to implement a custom operation as a simple method, the same way as you would write an ASP.NET Web API method. After putting a placeholder GenericODataApplication application in the appropriate folder in the Content Repository, you can start creating your custom method in your project. For the details, please check this article:


A Scenario is a group of actions one usually displays together. You can think of it as a context menu definition. A scenario is defined bottom-up, by setting the appropriate scenario keyword on each of the applications you wish to access. sensenet has a powerful caching system in place, enabling it to collect all needed actions in a scenario in a flash.

The action controls above (for example the ActionMenu) are able to filter and display actions by scenario. The action framework API also lets you query actions this way. See examples below.

Back URL

The Action URL can contain a parameter called back. The portal uses this value when there is a need to return (redirect) to the previous page after an operation - e.g. editing content properties. It is possible for portal builders to control the behavior of actions: whether to include the backurl or not. The default behavior of the portal is the following: all actions contain the backurl parameter except the Browse action.

You can control the visibility of the back url parameter in the following places:

It is recommended that you set this value to False in your application content if you are sure that the user will not return after visiting that application but will continue to browse the portal ‘forward’ and the back parameter is not necessary. Otherwise URLs can grow long and can cause unexpected browser behavior.

Back target

The Action URL can contain a parameter called backtarget. The portal uses this value in a similar way as the back URL above: where to redirect the user after completing the task on the page. The difference is that the backtarget parameter values are not exact URLs but tokens that can refer to a certain junction on the portal. The available tokens are the following:

If a back target value is given in the URL the portal will use it instead of the back URL. The only exception is when the action was not completed (e.g. when a user hits the Cancel button on a content creation page); in that case the back URL will be used (if exists).


Some example action links may be:

Working with Scenarios

There is nothing more to creating a Scenario than making up a name (keyword) for it, and adding it to all the applications you wish to access through it. Action presenter controls and Action query API calls usually accept a Scenario name, and automatically list all valid Actions found under that name.

Say, you wish to create a forum control panel, which will enable moderators to edit or delete Posts, and to lock or move Topics. First of all, you need a name for the scenario. ForumAdmin seems fine.

In our example, the applications for Posts and Topics are distributed as such:

Is something missing? See something that needs fixing? Propose a change here.