# Matomo.AddScheduledReport: Matomo Matomo tracking actions Matomo.AddScheduledReport: Matomo Matomo tracking actions Create a scheduled report definition. Documentation Wraps ScheduledReports.addReport - design chapter 7d's write side, exposed as a procedure rather than a generic-path insert on ScheduledReports.Reports because both addReport's 'reports' and 'parameters' arguments are PHP bracket-array form fields (reports[]=..., parameters[key]=...), not the single JSON-text value this driver's generic insert path (Matomo.ParametersToFormBody) can build from one column - confirmed live 2026-08-26 that a JSON-text 'reports' value is rejected outright ('must be of type array, string given'), not merely ignored, correcting this procedure's own first round, which had wrongly inferred the JSON-text shape worked from a call that failed earlier, on 'parameters', before ever reaching the reports check. report_unique_id therefore names exactly one report; a multi-report call needs several repeated reports[]= fields, which this procedure's own single-value PSQL parameters cannot build any more than the generic path could - the same bracket-array encoding gap already deferred for TagManager. Only the two most commonly-needed parameters entries (displayFormat, emailMe) are exposed as their own procedure parameters; evolutionGraph and additionalEmails follow the same nested shape and are not yet reachable through this procedure. idSegment/evolutionPeriodFor/evolutionPeriodN/periodParam all take Matomo's own defaults (no segment filter, evolution compared against the previous period).Parameters of Procedure The following parameters can be used to control the behaviour of the procedure `Matomo.AddScheduledReport`. A value must be provided at all times for required parameters, but optional parameters in general do not need to have a value and the execution will default to a pre-defined behaviour. Values can be specified by position and by name. In both cases, all parameters not specified will be evaluated using their default values. Value specification by position is done by listing all values from the first to the last needed value. For example: a `begin package.procedure(value1, value2, value3); end` on a procedure with four parameters will use the default value for the fourth parameter and the specified values for the first three. Value specification by name is done by listing all values that require a value. For example with `begin package.procedure(name1 => value1, name3 => value3); end` on the same procedure will use the default values for the second and fourth parameters and the specified values for the first and third. | Name | Data Type | Required | Default Value | Documentation | |---|:---:|:---:|:---:|---| | `id_site` | `int32` | ☑ | | Matomo site the report's own data is drawn from. | | `description` | `string` | ☑ | | Report title, shown in Matomo's own UI and used to build the sent filename. Truncated to 250 characters by Matomo. | | `period` | `string` | ☑ | | Delivery schedule: 'day', 'week', 'month' or 'never'. | | `hour` | `int32` | ☑ | | Hour of day (0-23) the report is sent at, for a period other than 'never'. | | `report_format` | `string` | ☑ | | Output format: 'pdf' or 'html'. | | `report_unique_id` | `string` | ☑ | | The one reporting table to include, by its unique ID, for instance 'VisitsSummary_get'. One report per call: a report definition in Matomo may hold several, but this procedure adds one. | | `display_format` | `int32` | ☑ | | Matomo's own mandatory display-format code for the 'email' transport - 1 for the classic per-table layout. | | `email_me` | `boolean` | ☐ | | Whether the calling user is also sent a copy. Matomo's own default is true when omitted. | | `evolution_graph` | `boolean` | ☐ | | Whether an evolution graph is included alongside each table. Matomo's own default is false when omitted. |