Skip to Main Content
Nintex Ideas

đź‘‹ Use this site to provide feedback and ideas for all Nintex Products. See our post on Nintex Community "Welcome to Nintex Ideas" for more details on Nintex Ideas, how an idea is handled by our product teams and more!

If you have questions about Nintex Ideas, please contact

If you require support, please visit Nintex Customer Central

If you have a sales inquiry, please contact

Status Open for voting
Categories Document Automation
Created by Guest
Created on Feb 1, 2022

Build API into Drawloop that can be called by using apex only

It would be good if Drawloop could have API’s that could be called directly via apex without needing tables (external or otherwise) or drawloop packages either.
So the API would just pass the id of the document template, and the data to be mapped to it, perhaps in a map or json structure where you could have a matchup like this:
"<>" : "Fred"
"<>" : "Smith"

So that given an document template, the data to go on it and the field tags could be sent via the apex API without requiring involvement from a Salesforce object or needing to create a Drawloop package. Perhaps the API would allow creation of a dummy Drawloop Package etc so it can be used.
    Sep 8, 2022
    This is an interesting suggestion! Can you tell us more about how you would use this?
  • Attach files
  • Guest
    Sep 8, 2022
    Hi Candace
    So a scenario might be that there is data in a system external to Salesforce (which is where Drawloop is currently installed). In that system there is some data that the business would like to have merged with a word template using Drawloop to produce a PDF to be sent to a customer.
    Currenlty to utilize Drawloop would require that the external systems data be sent to SF and stored in an object in SF, which might need a new custom object just to store that data so that the drawloop package can then reference it.

    I was thinking that apart from creating a drawloop package, the external data might be sent to drawloop directly via a JSON payload perhaps where the payload would represent the data records to be processed and be of the pattern
    {field_name_tag1 : data value1,
    field_name_tag2 : data value2 } etc. Could also have arrays in there.

    The document in the drawloop package would reference that data by using the tags <> and <> etc.
    The drawloop package, instead of nominating a starting object might nominate 'JSON Payload'.

    So when the inbound transaction comes in (probably a REST API call with a JSON payload), it invokes an Apex class and that class, amongst whatever else it may need to do will make a call out to Drawloop, perhaps in the form of something like this:
    PageReference dDPPage = new PageReference(
    '/apex/loop__looplus?sessionId=' + sessionID + '&autorun=true&ddpIds=' + DDP_Id_to_run + '&json1=' + jsonPayload1String + '&json2=' + jsonPayload2String
    return dDPPage;

    where the variable 'DDP_Id_to_run' holds the DDP id and the jsonPayload variables hold the record data to be merged into the documents. These payloads could be string or serialised json payloads.

    Or perhaps by having the apex class construct & send an outbound message instead with similar parameters.

    Simple relationships could still be handled, possibly, by having json variables be referenced, ie etc.

    Essentially, Nintex could construct an api that could receive all the data that a Drawloop package would normally access, but just receive it on a case by case basis as a transaction.
    If the template document id was sent then maybe a Drawloop package would not be needed either as the document id would point to the doc to be merged with etc, for simple cases.

    This would just allow a more dynamic use of Drawloop which would allow the passing to it of data that was not necessarily in a SF table but that could still be processed by a Drawloop package.

    Anyway, i was thinking along those lines, hope it helps
    kind regards