--- title: "August 7, 2026" slug: "august-07-2026" updated: 2026-08-04T13:23:49Z published: 2026-08-04T13:23:49Z canonical: "learn.servitly.com/august-07-2026" --- > ## Documentation Index > Fetch the complete documentation index at: https://learn.servitly.com/llms.txt > Use this file to discover all available pages before exploring further. # August 7, 2026 ## Reports for organization users In addition to customer and partner users, you can now define reports that are generated and sent to your organization users. ![](https://cdn.document360.io/6759e9c9-3ce3-49df-965a-7231d2d9a10a/Images/Documentation/Report type selection.png) This lets your internal teams receive automated PDF-based periodic insights that were previously available only to external business entities. Organization reports are useful for back-office monitoring, service oversight, and internal reviews, without the need for external tool integrations. ## Reports for specific users Until now, a report was delivered to all users of a business entity. You can now limit a report to a specific set of users by user type. ![](https://cdn.document360.io/6759e9c9-3ce3-49df-965a-7231d2d9a10a/Images/Documentation/Limit report receiver via User Type(1).png) So that each audience receives only the reports relevant to its role. ## Reports inheritance across the Thing Definition hierarchy Reports defined on a Thing Definition can now be inherited from its super Thing Definitions, following the same model as other configuration elements that can be [inherited](/v1/docs/thing-definition-inheritance). Define a report once on a parent Thing Definition and it becomes available to all derived ones, with no duplicated configuration. When a specific Thing Definition needs different content or scheduling, you can override the inherited report or template locally. ![](https://cdn.document360.io/6759e9c9-3ce3-49df-965a-7231d2d9a10a/Images/Documentation/Reports inheritance across TD hierarchy.png) ## Download the source code of your components In the Console, you can now download the source code of the custom components you developed. ![](https://cdn.document360.io/6759e9c9-3ce3-49df-965a-7231d2d9a10a/Images/Documentation/Components source code dowload.png) You can select components and versions to export. The result archive contains the JSON descriptor, JavaScript, CSS, HTML templates, images, and labels that make up each component. Exporting the component sources and downloading the [Configuration Code](/v1/docs/environment-configuration-management#configuration-code) gives you a complete copy of your work that you can save in your source code repository. ## Work Session management APIs A new set of API endpoints lets you manage Work Sessions programmatically, including creating and updating both active and historical work sessions. Until now, work sessions were driven mainly by the start/stop conditions evaluated on incoming metric values; you can now also create and maintain them directly from external systems. This opens up integration scenarios where the jobs and tasks performed by a product are tracked outside the DPS, for example, in an MES, ERP, or edge gateway, and then pushed into the platform. You can open and update an active work session as the job progresses, record completed sessions in the history, and correct or enrich existing ones. Combined with work session additional properties, this gives you full, API-driven control over the work session lifecycle and the data attached to it, feeding the same statistics, lists, and reports available in the DPS. ## Work Session additional properties You can now enrich Work Sessions with custom properties, capturing domain-specific information about each job or task beyond the monitored metrics and post-computations. Typical uses include batch or lot codes, product and recipe references, operator notes, or quality outcomes. This enriched context makes each work session more meaningful for traceability, statistics, and reporting. ![](https://cdn.document360.io/6759e9c9-3ce3-49df-965a-7231d2d9a10a/Images/Documentation/image-GRRT10QA.png) Custom property values can be populated in two ways: via API or manually by users directly from the [Work Session Details](/v1/docs/work-session-details-widget) widget in the DPS. This flexibility lets you combine automated data capture with information that operators or service users add on site. In the Console, on the [Work Sessions](/v1/docs/work-sessions) page, you can define the additional properties by clicking the *Work Session Properties* link present in the page footer. ![](https://cdn.document360.io/6759e9c9-3ce3-49df-965a-7231d2d9a10a/Images/Documentation/Footer link - Work Session Properties.png) The defined properties will then be referenced within each work session definition. ## Snowflake authentication update The [Snowflake](/v1/docs/snowflake) data integration can now authenticate using a key pair (RSA) instead of a username and password. This brings the plugin in line with [Snowflake's new authentication mechanism](https://docs.snowflake.com/en/user-guide/security-mfa-rollout#deprecation-timeline). ## Bug fixes (DPS) - The unit defined on metrics or post-computation outputs was discarded by the Work Session Details widget. - Filters were not correctly applied in the summary table of the Metric State Diagram widget. - The Envet List widget did not include sub-things’ events recursively. ## Bug fixes (Console) - In the template visual editor, the SUM function was not available for properties of type *AGGREGATION*. - The Value widget ignored the period selected on the page if a loading period had been configured within the widget itself. - In the template visual editor, the duration property was not available on work session-based widgets.