Configuring FSM Program

Configure the project rules that plan cases and the case rules that create CRM tasks. For the capability and processing behavior, see FSM Program.

This topic includes the following sections:

• Properties and Defaults

• Default JSON

• Related-data lookups

• Changing Program Rules

• Changing the Service Pattern and Creation Timing

• Changing Values Carried to Cases and Tasks

• Project values on new Cases

• Linked Project times and assignee on new Tasks

• Aliases, formulas and joined values

• Case scheduling values, Task priority and work-order references

• Dependencies and Customization Limits

• Contract changes and Case Type separation

• Projects created from a Case

• When Changes Apply

Properties and Defaults

The following table lists Program properties, record settings, defaults, and effects.

Property or Setting	Location	Accepted Value	Default	Effect
projectRules	program	Project rule array	[]	All matching rules contribute planned cases. The standard configuration supplies no schedule.
caseRules	program	Case rule array	[]	All matching rules contribute tasks. A case alone does not guarantee tasks.
projectMap, caseMap	program	Field maps	Asset and customer mappings. Case mappings also include assignee.	Supplies values available as project or supportcase in rule template tags.
projectData, caseData	program	Named related-data definitions	Related asset and customer. Case data also loads the linked project, including its type.	Supplies additional named data for template tags. Preserve the linked project lookup when case rules use Project Type or project data.
projectInactive	program	Project status-ID array	[3]	Stops case creation and enables removal assessment for qualifying cases.
caseInactive	program	Case status-ID array	[1]	Classifies cases removable under an inactive project.
Field Service Project Type	Project custentity_nx_project_type	Project Type ID	No Program type supplied by the rules.	Required for Project-to-Case calculation and selection of applicable project rules.
Start Date	Project startdate	Date	Existing record value.	Sets the required lower boundary for initial occurrences and anchors the pattern when Program Start Date is empty.
End Date	Project enddate	Date	Existing record value, optional when a usable rolling horizon is supplied.	Upper boundary for initially calculated occurrences, taking precedence over the rolling horizon as that boundary.
Program Start Date, also labeled Field Service Start Date	Project custentity_nx_start_date	Date	Project Start Date when empty.	Anchors the schedule pattern without removing the Project Start Date lower boundary.
Program Create Until	Project custentity_nx_program_create_until	Nonnegative integer. A value of 0 means no rolling horizon. Measured in days ahead of the current date.	Empty in the supplied field definition.	Supplies a rolling creation horizon and can supply the calculation end when Project End Date is absent.
Field Service Time Zone	Project: custentity_nx_time_zone. Case: custevent_nx_time_zone.	FSM Time Zone record ID	Supplied through normal record processing.	Initial time zone sourcing and rolling horizon calculation.
Field Service Update Program	Project: custentity_nx_program_update. Case: custevent_nx_program_update.	Checkbox	Existing record value.	Saved project requests assess case additions and removals. Saved case requests assess missing child tasks.

Program initially carries the project's value to generated cases and the case's value to generated tasks. The project's time zone determines the rolling horizon. If the project's time zone is empty, calculation uses the time zone preference of the person running the process.

Use internal IDs for types and statuses from your account. Do not assume that labels or IDs have the same meaning across accounts. Project statuses outside projectInactive are active for Program calculation. A status labeled Closed is not automatically inactive. The caseInactive property controls removal under an inactive project, rather than disabling task generation on that case.

A project needs its type, Start Date, and End Date or a positive usable Program Create Until value even when a rule requests only one occurrence. For background Case-to-Task processing, a case needs a Case Type, Field Service Start Date, and applicable rules. An asset or customer is needed when required by the chosen rules, related-data definitions, or destination record.

Use forms that expose the required record fields. Add account-specific source and destination fields to the appropriate records and forms before referencing those fields in rules, with compatible field types and access. Form layouts in examples are illustrative, rather than requirements for a particular custom form. For shared editing, merge, and activation instructions, see FSM Configuration.

Default JSON

The following JSON fragment shows the standard defaults for all eight Program properties. Other model mappings and record defaults remain inherited. The empty rule arrays supply no schedule.

            {
  "program": {
    "projectRules": [],
    "caseRules": [],
    "projectInactive": [
      3
    ],
    "caseInactive": [
      1
    ],
    "projectMap": {
      "asset": "custentity_nx_asset[integer]",
      "customer": "custentity_nx_customer[integer]"
    },
    "caseMap": {
      "asset": "custevent_nx_case_asset[integer]",
      "customer": "custevent_nx_customer[integer]",
      "assigned": "assigned[integer]"
    },
    "projectData": {
      "asset": {
        "record": "customrecord_nx_asset",
        "filters": ["internalid", "anyof", "${ project.asset || 0 }"],
        "map": {}
      },
      "customer": {
        "record": "customer",
        "filters": ["internalid", "anyof", "${ project.customer || 0 }"],
        "map": {}
      }
    },
    "caseData": {
      "asset": {
        "record": "customrecord_nx_asset",
        "filters": [
          ["internalid", "anyof", "${ supportcase.asset || 0 }"],
          "and",
          ["formulatext:ROWNUM", "is", "1"]
        ],
        "result": 0,
        "map": {}
      },
      "customer": {
        "record": "customer",
        "filters": [
          ["internalid", "anyof", "${ supportcase.customer || 0 }"],
          "and",
          ["formulatext:ROWNUM", "is", "1"]
        ],
        "result": 0,
        "map": {}
      },
      "project": {
        "record": "job",
        "filters": [
          ["internalid", "anyof", "${ supportcase.company || 0 }"],
          "and",
          ["formulatext:ROWNUM", "is", "1"]
        ],
        "result": 0,
        "map": {
          "type": "custentity_nx_project_type"
        }
      }
    }
  }
} 

          

Related-data lookups

The names under projectData and caseData become template contexts when the corresponding rules run. These contexts are separate from the current record's project or supportcase inputs.

The following table summarizes lookup results and configuration dependencies.

Definition	Lookup and Result Shape	Configuration Dependency
projectData.asset, projectData.customer	Searches the mapped asset or customer ID on the project. Returns an array of search results because result is omitted.	Keep the project's asset and customer input mappings compatible with these filters. Add required related fields to the relevant map and use tags that match the returned shape.
caseData.asset, caseData.customer	Searches the mapped asset or customer ID on the case, using the standard filter for the first row. The result: 0 setting selects the first returned object, or supplies no object when no match exists.	Keep the case's asset and customer input mappings and the result position compatible with tags that use this data.
caseData.project	Searches job using the case's mapped company ID, the standard filter for the first row, and result: 0. Maps custentity_nx_project_type to project.type.	Supplies the linked Project Type for case rule conditions and linked project data for task outputs. Preserve the record, filters, result position, and type mapping when extending the map.

The filters use 0 when the mapped relationship ID is missing. A customer in the case's Company field does not supply a resolved project. The linked project search must return a project for project.type to be available.

An empty configured map does not indicate that every field on the related record is loaded. Program can add a missing direct-field mapping to an existing named data definition when a rule tag references that field. Aliases, formulas, joins, and formatted values still require compatible explicit mappings. Changing a lookup to return an array instead of a single object, or the reverse, changes the tag paths for its result. For reusable search and mapping syntax, see FSM Searches and Field Mapping.

Changing Program Rules

A rule distinguishes its type conditions from the records it produces. Project rules match the project type. Case rules match the case type, the resolved type of the linked project, or both. If both conditions are supplied, both must match. Every matching rule contributes work, so a broader rule can also apply alongside a more specific rule.

Project rules receive Project Type as the condition context. Case rules receive Case Type and the resolved type of the linked project. Additional mapped fields and related data are available to template tags. These values do not add arbitrary condition properties to the context. Program evaluates type conditions before resolving the output tags for a matching rule.

The following table lists rule properties, defaults, and effects.

Rule Area	Property or Default	Effect
Project rule conditions	project	Matches the project type. A mapping or template-data value does not automatically become another selection condition.
Project rule output	case	Case Type ID, or object containing type and supported case values.
Case rule conditions	case, project	Match the case type and the linked project type resolved through caseData.project.
Case rule output	task	Task Type ID, or object containing type and supported task values.
Both rule families	Integer offset (examples use zero or positive values) and positive integer interval	Omitted values use 0 and 1. Offset moves the first occurrence. The interval spaces later occurrences in the selected unit.
Project rules	unit: "day" or "month"	Month-based when omitted. Specify explicitly.
Case rules	unit: "day" or "month"	Day-based when omitted. Specify explicitly.
Project total	Positive count	No finite count limit when omitted, although the source date boundary still applies. Earlier occurrences excluded by Project Start Date still consume the count.
Case total	Positive count	One task when omitted.
Project create	Boolean value. Defaults to false when omitted.	true requests all planned missing cases when no rolling horizon applies. A value of false retains creation of the next required case.
Project shift	Boolean value. Defaults to false when omitted.	true shifts later unmatched planned dates using a matched case date difference. This is independent of create.

A rule output can be a single type ID or an object. For example, "case": 104 is equivalent to "case": {"type": 104}. Similarly, "task": 205 is equivalent to "task": {"type": 205}. Use the object form to supply additional supported destination values. If the output type is omitted, Program supplies no default Case Type or Task Type. Include the intended type ID from your account.

The following table lists properties excluded from condition matching.

Rule Family	Output and Pattern Properties
Project rules	case, offset, interval, total, unit, shift, create
Case rules	task, offset, interval, total, unit

In a project rule, case is the case output, not a Case Type condition. In a case rule, case is a condition and task is the task output. The create and shift properties control project rules and do not control case rules. For all-condition, alternative-value, and Boolean matching semantics, see Shared Rule Matching. Program uses every matching rule, whereas resource selection uses the first match.

For type conditions, one ID and an array are both valid: "project": 3, "project": [3], or "project": [3,4,5]. Omit a condition to leave it unrestricted. In a case rule, "project": true requires the resolved type of the linked project to be populated. The condition "project": false matches a missing resolved Project Type. These Boolean values do not test only whether the case's Company is a project. Selecting New Project does not supply the resolved type. That type becomes available after the project is created and linked. Use specific Project Type IDs when only those types should qualify.

The offset and interval properties use unit: "month" for calendar months or "day" for days. The default unit differs between project and case rules, so specify unit in examples. A project total counts occurrences from the pattern's anchor. It does not guarantee that the same number of cases will be created within the project dates. Do not use a count to bypass the required end boundary. A case total limits tasks for that rule. Omitted total means one task, rather than an unlimited series.

The first calculated case date is the project's pattern anchor plus offset. The first calculated task date is the case's Field Service Start Date plus offset. With the omitted offset of 0, each sequence starts on its respective anchor. Project occurrences before Project Start Date are excluded but still consume a finite total. The case's Field Service Start Date is the lower boundary for calculated task occurrences. The case's End Date does not cap that rule. A calculated task occurrence before the case start is excluded and still consumes the finite count. Program applies destination date outputs after the initial date selection, so output values can fall outside these boundaries. Project shifting is a separate effect described in Changing the Service Pattern and Creation Timing.

Emptying either rule array prevents those rules from contributing planned work. This change does not remove existing cases or tasks.

Note:

The worked examples contain illustrative type IDs, employee IDs, and custom field IDs. Replace these values with valid values from your account.

For example, plan six-monthly cases and one task per matching case:

            {
  "program": {
    "projectRules": [
      {
        "project": [
          103
        ],
        "case": {
          "type": 104
        },
        "unit": "month",
        "interval": 6,
        "total": 4
      }
    ],
    "caseRules": [
      {
        "case": [
          104
        ],
        "task": {
          "type": 205
        },
        "unit": "day",
        "offset": 0,
        "total": 1
      }
    ]
  }
} 

          

Type IDs 103, 104, and 205 are illustrative. Use the type IDs for projects, cases, and tasks from your account. These arrays replace their matching arrays, so include all required rules. The project still needs its type, Start Date, and End Date or usable rolling horizon. This topic defines the Program-specific maps, related-data defaults, and rules. For reusable mapping syntax, see FSM Searches and Field Mapping.

The case rule in this example applies to type 104 regardless of linked Project Type. Add the intended project condition when task generation depends on a particular linked project.

Changing the Service Pattern and Creation Timing

For alternating Minor and Major service every six months, give each type a twelve-month interval and offset the Major rule by six months. This illustrative replacement for program.projectRules uses Project Type 46, Minor Case Type 27, and Major Case Type 28:

            {
  "program": {
    "projectRules": [
      {
        "project": [46],
        "unit": "month",
        "interval": 12,
        "offset": 0,
        "create": true,
        "case": {
          "type": 27,
          "details": "${project.comments}",
          "custevent_nxc_department": "${project.department}",
          "assigned": 5
        }
      },
      {
        "project": [46],
        "unit": "month",
        "interval": 12,
        "offset": 6,
        "create": true,
        "case": {
          "type": 28,
          "details": "${project.comments}",
          "custevent_nxc_department": "${project.department}",
          "assigned": 5
        }
      }
    ]
  }
} 

          

The custom department field and employee ID 5 are account-specific examples. Use a compatible case department field and the intended employee in the account. The offsets establish the sequence. Changing the order of the rules alone does not change their dates. With Project Start Date January 1, 2026, and no separate Program Start Date, the first dates are Minor on January 1 and Major on July 1. Set Program Start Date to December 10, 2025 to preserve the earlier pattern. The Minor occurrence before the project Start Date is omitted. The first included occurrences are Major on June 10, 2026, and Minor on December 10, 2026. With a finite total, that omitted earlier Minor still consumes an occurrence. See FSM Program for the other date examples and bounds.

The following table compares creation timing options.

Desired Timing	Setting Combination	Consequence
Next required case	When no rolling horizon applies, omit create or set it to false.	Selects the first planned row without an end date. Creates a case only if that row has no matched case. A matched case without Field Service End Date prevents progression.
Advance creation	Set a positive Program Create Until on the project.	Additional missing cases at or before the rolling horizon qualify for creation. This horizon takes precedence over create for advance creation.
All planned cases	When no rolling horizon applies, set create: true.	Requests all missing cases in the calculated schedule through its applicable date and count boundaries.

When Project End Date and a rolling horizon are both present, End Date limits the initial calculated pattern. The horizon selects additional missing cases for advance creation. Next required case selection can select a missing row beyond that horizon if the row remains in the calculated pattern. Program recalculates the horizon during assessment. Passing time alone does not guarantee another execution.

For a next required case pattern, set shift: true to move later unmatched dates relative to a matched case. Program uses the difference between the case's planned date and its Field Service End Date. If no end date exists, Program uses the case's start date instead. For example, a pattern repeats every six months, with planned dates of January 1 and July 1. An actual end date of February 7 can move the unmatched July date to August 7. The shifting calculation is independent of create and does not reschedule matched existing cases. Shifted dates and configured output dates can fall outside the initial project date bounds.

Changing Values Carried to Cases and Tasks

Use projectMap for project inputs and caseMap for case inputs. projectData and caseData provide related records under their named template context, such as asset, customer, and project. A case rule can use linked project data through the inherited caseData.project definition without first copying every value onto the case.

The projectMap and caseMap properties extend the effective input maps, including applicable record-model mappings. These effective maps also include Program's identity, type, status, time zone, and date mappings. Program uses the effective case map to write generated cases. Generated tasks use the Program task map. Keep source aliases distinct from destination fields. A named input or related-data value does not automatically become a writable case or task property. For reusable model mappings and default definitions, see FSM Record Model Configuration.

Case destination aliases include type, details, assigned, startdate, starttime, enddate, endtime, and timezone. Task destination aliases include type, assigned, startdate, starttime, enddate, endtime, and timezone. The details property is not a supplied task alias. Use compatible writable native field IDs for additional outputs. The projectMap property supplies input data for project rules. This property is not the destination map for generated cases.

Program can automatically add a missing direct-field mapping referenced by a tag such as ${project.comments}. An explicit alias, formula, join, or formatted value still needs the appropriate mapping. This automatic mapping does not make an arbitrary field or join valid. A field with an account-specific nxc ID is not a standard NetSuite field merely because it can be referenced by its native ID. Keep useful aliases and formatting. Removing mappings is not a general prerequisite for Program.

Use the mapped name in a template tag. In the following example, projectassets supplies ${project.projectassets}. Date, time, and multiselect inputs need compatible formats such as [date], [time], and [array]. These formats describe the value. The formats do not create fields or change the NetSuite field type. For formula, join, and format syntax, see Mapping Search Results. For template tag syntax, see Using Template Tags.

Project values on new Cases

This illustrative annual rule carries the project's asset, a custom multiselect asset list, and project comments onto generated cases. The custom project and case fields must exist and accept the same asset selections. The explicit case mapping preserves multiselect formatting when that destination is written.

              {
  "program": {
    "projectMap": {
      "projectassets": "custentity_nxc_project_assets[array]"
    },
    "caseMap": {
      "custevent_nxc_case_assets": "custevent_nxc_case_assets[array]"
    },
    "projectRules": [
      {
        "project": [3],
        "case": {
          "type": 3,
          "custevent_nx_case_asset": "${project.custentity_nx_asset}",
          "custevent_nxc_case_assets": "${project.projectassets}",
          "details": "${project.comments}"
        },
        "interval": 12,
        "unit": "month",
        "create": true
      }
    ]
  }
} 

            

The details alias is the Program case mapping for custevent_nx_case_details. Use this alias when replacing the generated series description. A literal "comments" writes that word. The template tag "${project.comments}" copies the project's comments. Other supported destination aliases include type and assigned. Use valid native field IDs for additional destination fields without an alias. Do not assume every output property is a valid writable field.

To carry project comments separately, create a case text field. Set that field in case and leave details unset to preserve the default series description. The same pattern can carry a project PO Number to an appropriate case field. Add the output to every intended project rule. The output supplies values at creation and does not continuously synchronize existing cases. For the sourcing scenario, see Field Source from Project to Case (PM program).

Linked Project times and assignee on new Tasks

Create Time-of-Day fields on the project for task start and end time, and a compatible Employee selection for task assignee. This fragment extends the inherited linked project lookup with formatted time mappings. Its custom fields and type IDs are examples. Retain every case rule needed by the account when replacing caseRules.

              {
  "program": {
    "caseData": {
      "project": {
        "map": {
          "starttime": "custentity_nxc_task_starttime[time]",
          "endtime": "custentity_nxc_task_endtime[time]"
        }
      }
    },
    "caseRules": [
      {
        "project": [3,4,5,6,7],
        "case": [3],
        "offset": 0,
        "unit": "day",
        "total": 1,
        "task": {
          "type": 1,
          "starttime": "${project.starttime}",
          "endtime": "${project.endtime}",
          "assigned": "${project.custentity_nxc_task_assignee}"
        }
      }
    ]
  }
} 

            

The related lookup's record, filters, and Project Type mapping remain inherited. The time values populate the task's Field Service start and end times in its service time zone. Choose values that satisfy normal task date and time requirements. Program initially uses the case's time zone for the task. That value can differ from an asset's time zone, and a selected assignee does not establish availability or resolve scheduling conflicts. Use starttime and endtime for these time outputs, rather than introducing start and end as task fields. For the source scenario, see Field Source from Project to Task (PM program).

Aliases, formulas and joined values

The following table shows account-specific mappings for the indicated Program maps.

Location and Mapped Name	Example Mapping	Use
projectMap.casetype	"formulatext:nvl({custentity_nxc_case_type},2)"	Supplies a fallback Case Type value as ${project.casetype}. Use valid account IDs.
projectMap.email	"contactprimary.email|"	Reads the primary contact's email without making it a project write destination.
caseMap.contract_tech_task	"company.custentity_nxc_contract_tech|[integer]"	Reads a linked Company's technician ID for task assigned: "${supportcase.contract_tech_task}".
caseMap.case_skill	"custevent_nxc_case_skill[array]"	Supplies a compatible case multiselect skill list for the task skill field.

The case skill field must contain IDs from the same Skill list as the task's multiselect field. A typed native output such as "custevent_nx_task_skill[array]": "${supportcase.case_skill}" preserves array serialization. Joined inputs must be valid search columns for the source record. A trailing | makes a mapping read-only. It does not add permission to write to the joined record. Preserve distinct mapped names when adding values so that a custom join does not unintentionally replace the case's normal start and end mappings.

Case scheduling values, Task priority and work-order references

This example creates one task with the case's start date, start time, and assignee. It uses an account-specific source for task priority and copies two work order values from the linked project. The custom fields must exist with compatible source and destination types. The priority source must supply a valid task priority value. Do not assume case priority IDs are interchangeable with task priority values.

              {
  "program": {
    "caseMap": {
      "taskPriority": "custevent_nxc_task_priority",
      "fsointernalid": "company.custentity_nxc_fso_id|",
      "fsojobtype": "company.custentity_nxc_fso_job_type|"
    },
    "caseRules": [
      {
        "project": [103],
        "case": [102],
        "unit": "day",
        "offset": 0,
        "total": 1,
        "task": {
          "type": 111,
          "startdate": "${supportcase.startdate}",
          "enddate": "${supportcase.startdate}",
          "starttime": "${supportcase.starttime}",
          "assigned": "${supportcase.assigned}",
          "priority": "${supportcase.taskPriority}",
          "custevent_nxc_fso_link": "${supportcase.fsointernalid}",
          "custevent_nxc_fso_job_type": "${supportcase.fsojobtype}"
        }
      }
    ]
  }
} 

            

The source case start time must be populated for this explicit copy. Omitted task time outputs use the configured task defaults. An explicit output replaces that value rather than automatically falling back when its source is blank. The same approach can carry a project's task priority through caseData.project instead of using a case field. The work-order fields are examples of account-specific references, rather than shipped Program defaults. Copying scheduling values supplies record values. It does not select an available resource, update matched tasks, or continuously synchronize changed source values.

Dependencies and Customization Limits

Warning:

Changing projectInactive or caseInactive can select existing cases for removal. Removing a qualifying case requests deletion of all its linked tasks, including tasks outside the rule's Task Type. Classify account statuses deliberately.

Preserve Company, case, and other required record relationships when setting output values. Rules can override initially supplied dates and other values. Such overrides must satisfy the destination record's requirements and do not provide continuous synchronization.

Program rule units use singular "day" and "month". These units differ from the plural units used by Recurrence's generation horizon.

Contract changes and Case Type separation

Recommended practice: If the contracted frequency, pattern, or terms change, end the original Program at the agreed changeover. Create a project for the revised service. Configure that project's type and rules for the revised service without rewriting rules still used by the original project. Keep completed work under the original project. Closing a project or shortening End Date does not remove all future work or make the project inactive for Program. Configured status classifications and conditions for removing matched cases still apply.

Recommended practice: Use distinct Case Types for project Program-created cases and Recurrence-created cases. Keep the Recurrence Case Type out of the project rules' case.type outputs when both features would otherwise generate cases for the same service obligation. A dedicated Recurrence Case Type may still have Program case rules for its child tasks. Separate case types are a configuration convention. Program does not prohibit Recurrence. Ensure Program case defaults, outputs, and other automation do not add a Recurrence association or pending Recurrence definition to cases created by Program. See FSM Program for the matching consequence.

Projects created from a Case

Recommended practice: When Case-to-Task rules need linked project data, require the resolved Project Type in every applicable rule. Use the intended IDs, or "project": true when any populated Project Type is acceptable. Broader rules that omit project or permit a missing type can still run before the project exists.

Selecting a New Project type on the case initially saves that case against its customer. A later callback creates and links the project. The standard New Project choices exclude types explicitly used by Project-to-Case rules. Task creation before linkage can retain interim values because Program does not revise matching tasks later. Save the case's Update Program request after linkage when missing child tasks should be generated. Linkage alone does not guarantee generation. For this timing boundary, see FSM Program.

When Changes Apply

Rule changes affect later schedule calculations and background assessments. Program does not automatically reschedule existing matched cases or update or delete existing matching tasks. Program matches existing cases and tasks by chronological order and type, rather than exact dates. Manual or recurring cases of participating types can affect which work Program considers missing. Program Start Date and Create Until are record values. Saving related changes can request processing.

A saved project Update Program request assesses case additions and removals. A saved case request assesses its missing child tasks, including on an already Closed case, and does not directly set the parent project request. Requests and displayed Program rows are not proof that records were created. Processing remains subject to current inputs, rules, classifications, and errors.

For completion outside FSM Mobile, save the case's actual Field Service End Date (custevent_nx_end_date) and applicable completion time. These values must be available when FSM processes the change to Closed. The native Date Closed (enddate) field in NetSuite is different. If completion values are added after the case is already Closed, save a project Update Program request for reassessment. The case request is for tasks. This does not guarantee another occurrence is eligible, and status automation does not generally backfill the completion values of an already Closed case. See FSM Program for the closure and request limits, and Configuring FSM Case and CRM Task Status Automation for the related settings.

Related Topics

Related Topics

• FSM Configuration
• FSM Program
• FSM NetSuite View Configuration
• FSM Record Model Configuration
• FSM Searches and Field Mapping
• FSM Expressions and Template Tags

General Notices