Blueprints are simple text blocks that provide any combination of configuration information, typically on a ‘module’ of functionality where all the related records are needed together to be valid and useful.
Blueprint text can be managed and maintained in whatever manner is convenient outside of PYXI – whether stored in text files, databases or manually keyed in, it doesn’t matter.
Blueprint syntax is designed to be machine-readable but still human-readable and therefore, to some extent, human-writable. For small, individual activities like adding a single record, specific API calls or use of the user-interface may be appropriate. For any more significant update, particularly where the same functionality is to be applied to multiple accounts, Blueprints are the most practical solution.
It is easiest to understand blueprints with examples.
This simple script adds two Group records – one with name of Finance, another with name of HR.
The record type is specified within square brackets.
The next line is one or more editable field names of that record type.
Subsequent lines are one record each.
This script adds a category used in sales pipeline functionality. It adds the AcquirePipeline record type, then adds a Field to Organisation linked to this record type, and finally adds the records for the individual values of the category itself (AcquirePipeline records).
Note that the blueprint syntax checker will correctly pass this script even though the AcquirePipeline record type does not yet exist when doing the check. The syntax checker correctly ‘remembers’ that the record type would be created earlier in the same script, so confirms correct syntax of the later section with its own records as well.
There is a standard syntax for specifying any field value that spans multiple lines – ‘<<<' where the field value starts, then the multi-line value itself on subsequent lines, and finally '>>>’ on the beginning of the next line. Note that the line beginning >>> can have further values after it if required.
This blueprint adds both a Rule and a Webhook. The Rule contains a multi-line ActionScript and is set to act whenever a Person record is edited. The ActionScript itself calls a Webhook, which has been set-up in the same Blueprint.
The Webhook record demonstrates the use of calculations within a blueprint – anything within curly braces is evaluated as a calculation – in this case, getting a config value which has, incidentally, also been set-up with the same script. The result of this is a webhook record called MyApp Webhook which has the URL http://myapp.com/webhooks/webhook.php