Projects are the top-level objects in smenso and form the structural foundation for organizing work. All tasks, subtasks, planning data, time records, absences, status reports, and metadata are associated with a project.

Projects in smenso are intentionally flexible and can represent a wide range of use cases - from small internal organizational initiatives to complex, long-running programs involving multiple teams, external systems, resource planning, and reporting requirements.

A project typically defines:

• the scope and timeframe of work,
• the people involved,
• structural elements such as tasks and subtasks,
• and optional metadata through flavors.

Projects can be created manually in the UI or programmatically via the API, either from scratch or based on predefined templates. Templates allow organizations to standardize project structures and master data while still supporting individual customization.

Create project without a template

This section explains how to create a brand-new project via the API without using an existing template. You provide the project’s core metadata directly in the request payload. This approach is useful when projects are generated dynamically from external systems, when each project is highly individual, or when you intentionally want full control over the initial structure. Below you’ll find the most important fields and a compact JSON example you can use as a starting point.

Fields

To create a project, only three fields are required:

• Title (string): The title of the project.
• PhaseId (string | number): The Project Folder value from the project master data. You can retrieve the PhaseId via a flavor of type "Formula".
• TypeId (string | number): The Project Type value from the project master data. You can retrieve the TypeId via a flavor of type "Formula".

Example

{
  "timezoneId": "W. Europe Standard Time",
  "externalIdReference": null,
  "project": [
    {
      "description": null,
      "goal": null,
      "startDate": null,
      "endDate": null,
      "departmentId": null,
      "locationId": null,
      "projectManager": null,
      "benefit": null,
      "statusId": null,
      "workflowId": null,
      "budget": null,
      "currency": null,
      "hourlyRate": null,
      "usePersonalHourlyRates": null,
      "blockTimeRecording": null,
      "flavor": null,
      "title": "Test",
      "phaseId": "Test",
      "typeId": "Test",
      "externalId": null,
      "tempId": null
    }
  ]
}

Create project with a template

This section explains how to create a new project via the API based on a template. Instead of defining everything from scratch, you reference a template that provides a predefined structure and default settings (e.g., phases, tasks, roles, checklists, or standard values). This helps keep projects consistent and reduces setup time - especially for recurring project types. Below you’ll find the key fields (including the template reference and optional overrides) and a short JSON example showing how to select a template and override specific values at creation time. Additional fields may be included in the request payload to override or extend template defaults.

What can be inherited from a template?

Depending on template and workspace configuration, a project created from a template may inherit:

• Master data (title patterns, default values, etc.)
• Flavors (custom fields)
• Structural elements (for example predefined tasks or template-related metadata)
• Status / categorization fields and other template settings

Fields

To create a project from template, the following fields and informations are required:

• Title (string): The title of the project.
• PhaseId (string | number): The Project Folder value from the project master data. You can retrieve the PhaseId via a flavor of type "Formula".
• TypeId (string | number): The Project Type value from the project master data. You can retrieve the TypeId via a flavor of type "Formula".
• templateId: The GUID of the project template (to be used in the endpoint URL)

How to get the templateID

Open the Details of the template and copy the GUID.

Example

• Path Parameters: https://{customerSubdomain}.smenso.cloud/skyisland/api/integration/project/json/{templateId}
• Body Parameters:

{
  "options": {
    "startDate": true,
    "adjustTaskDates": true,
    "tasks": true,
    "flavors": true,
    "labels": true,
    "manager": true,
    "tasksWorkflow": true,
    "tasksTemplate": true,
    "folderTasksTemplate": true,
    "viewSettings": true,
    "budget": true,
    "location": true,
    "description": true,
    "hourlyRate": true,
    "goal": true,
    "benefit": true,
    "observers": true,
    "permissions": true,
    "blockTimeRecording": true,
    "markedColumns": true,
    "columnDescriptions": true
  },
  "title": "Test123",
  "folder": "Test",
  "projectType": "Test"
}

Update project master data with a template

Use this endpoint to extend or adjust the master data of an existing project based on a project template. This is especially useful when templates evolve over time - for example, when new master-data fields (e.g., additional metadata / flavors) are introduced and should also be applied to projects that already exist.

Scope: master data only

This operation affects master data only. It does not apply or modify project structure (such as tasks, folders/phase structures, checklists, dependencies, etc.). The endpoint is intentionally designed for keeping an existing project’s metadata aligned with template changes - without changing its structural content.

Selective update behavior (explicit only)

The update is strictly selective:

• Only attributes explicitly included in the request payload are updated.
• Attributes not referenced remain unchanged.
• There are no implicit defaults and no “auto-sync”: if a section/field is not present in the request, it will not be touched.

This allows you to safely roll out template changes to existing projects and control exactly which master-data areas should be updated or extended.

Flavors / custom fields overwrite behavior

For flavors (custom fields), existing values can optionally be overwritten only if the request explicitly enables this behavior (via the dedicated overwrite setting/flag for flavors). If overwrite is not enabled, existing values remain unchanged and only missing values can be added.

Important notes

• For project creation via the Integration API, the Id element must still be included in the XML payload. Use an empty value (for example Id with no content). If Id is missing entirely, the request fails validation.
• Archived projects cannot be updated. Attempting to update an archived project may lead to an unintended create (the archived project is treated as “not found”, and a new project can be created instead). Make sure the project is not archived before sending updates.

This guide describes the general behavior of projects in smenso and applies equally to the JSON API, XML Integration API, and Reporting API.