ApproveIT 365 allows for customization during all processes with the help of events.
Check the Events page to see an overview for all available integration events.
Besides changing or expanding the ApproveIT 365 processes, it is also possible to use customization to add support for custom source documents.
The following scenario’s are possible and explained below:
Use ApproveIT 365 on supported entities with a custom/third-party document type (e.g. Sales document with custom document type Contract).
Use ApproveIT 365 on custom/third-party entities (e.g. Transport Order from the ShipIT 365 extension).
For both scenarios example files are available in the following download:
| View file | ||
|---|---|---|
|
1. Supported entities with a custom/third-party document type
In this example we use the Sales Header table as an example and create a custom Sales Document Type Contract.
Since ApproveIT 365 uses the RecordRef for the source document in the process and all ApproveIT 365 fields already exist in the Sales Header table in the standard solution we only need to fields and actions to the pages for the Sales Contract.
In the example project the following AL files are included:
...
ApproveIT 365 checks the report selection usage to determine the report selection for the report id and layout. There are files included in the example project to manage the report selection usage for the Sales Contract. This is only required if the custom/third-party solution does not contain a way to handle the report selection usage to determine the correct report to use.
While not required for the processing of the ApproveIT 365 flow, the page fields can be added to give feedback to the users what the current DocuSign status is and who processed the document.
On the page for the source document (see SalesContractCard.Page.al as an example), the following page fields can be added.
...
This will result in the following section on the page in the webclient:
...
The ApproveIT 365 page actions allow the users to start the ApproveIT 365 flow from the source document, as well as follow-up the document status.
The following page actions can be added to allow for all actions currently available on the supported document types.
...
This will result in the following actions on the page in the webclient.
This screenshot pressumes that action references were added for the ApproveIT 365 actions in the Promoted area:
...
Because the source table (Sales Header) is already supported in the standard ApproveIT 365 solution, this should be enough to successfully process the custom/third-party document type with ApproveIT 365.
| Info |
|---|
If the custom document type is from a third-party extension, use page extensions instead to add the page fields and page actions. |
2. Custom/third-party entities
In this example we use the Transport Order Header table from our ShipIT 365 extension as an example.
Since this entity is not known in the Business Central Base Application, it can’t be supported in the standard solution.
However, by adding a dependency to the ShipIT 365 extension, we can add the ApproveIT 365 flow to this entity with customization.
In the example project the following AL files are included:
...
Before creating a page extension for the Transport Order Card, table fields should be added to the Transport Order Header table.
These fields can be added in a table extension (example TransportOrderHeader.TableExt.al).
...
After this, a page extension can be created for the Transport Order Card (example TransportOrderCard.PageExt.al) to add the page fields and page actions.
This can be done in the same way as described in the first scenario for the Sales Contract.
However, in the processing of the page actions, one additional step should be taken.
Since ApproveIT 365 uses a RecordRef variable in the standard processes, it doesn’t know what field numbers are added in the table extension.
But to update the fields with the correct DocuSign Envelope Id, status, user and date/times this information should be included before calling the standard ApproveIT 365 procedures.
This can be done by defining the source document field numbers.
Below is an example for the Void Envelope action. Before calling the ProcessMgt.VoidEnvelope() procedure, the procedure IDYACSetSourceDocFields() is called.
...
This procedure gets the field numbers and stores them in a JsonObject variable and calls the ProcessMgt.SetSourceDocFieldNos() procedure.
By setting these field numbers, the ApproveIT 365 processes will know that non-standard field numbers should be used for the source document.
If this procedure is not called, ApproveIT 365 will continue with using the standard fields in the object range for the standard extension.
...
In the GetSourceDocFields procedure the field numbers can be added to the SourceFieldNos variable.
The following fields are expected in this JsonObject:
status: Field number to store the ApproveIT 365/DocuSign status.
envelopeId: Field number to store the DocuSign envelope Id.
envelopeSentAt: Field number to store the date/time when the DocuSign envelope was created/sent.
languageCode: Field number to store the language code for the source document to determine the report language (set to 0 if this is not available).
...
Some additional event subscribers might be required to get the ApproveIT 365 flow to work correctly.
Some examples have been added to the TptProcessManagement.Codeunit.al file to manage the following:
Set a custom report selection usage to determine the correct report.
Set the default recipient in the Recipients page based on the source document with custom logic.
Set a custom document name for the attachment that is retrieved from DocuSign after signing.
Set a custom notification message including the source document number after sending the document to DocuSign.
Add the custom entity (Transport Order Header) to the Job Queue Entry process to get the status for all open DocuSign envelopes and set the custom field numbers for this process.
These event subscribers and procedures can be found in the codeunit, including a summary for each subscriber.