Run details and status

Package Builder records the result of every run in two places on your app: the status field on the master record, which shows how the whole run ended, and the optional Run Details table, which gets one row for each step that ran. Both are written for runs from the button and for runs in the background, so they're the first place to look when a package isn't what you expected.

The status field (stsfid)

The installation wizard adds a text field named Package Builder Status to the master table and puts its field ID in the stsfid parameter of both Package Builder fields. Always include stsfid: it's how Package Builder reports back, and background runs have no other way to tell you they're done.

Package Builder writes the field once, when the run ends, and replaces whatever was in it. If you start background runs by changing this field (see Run a package in the background), the result replaces that value. From the button, the run ends when the last step finishes or a required step fails. If the user closes the progress window early, the step that was already running still finishes on our server; if that was the last step or a required step that failed, the field is still written. Otherwise the remaining steps don't run, and the field may not be updated for that run.

Message format and timestamp

Every status has the form <message> on <date and time>, for example Process Successfully Completed on 10/6/2026 9:14:31 AM. The date and time are when the run ended, in our server's local time, so they may not match your time zone. Some messages add more lines below the first one.

In these messages, <Add-on> is the value of the template's Add-On field, such as XL Docs or Static Document, and <Record ID#> is the template's Record ID# in the Document Templates table. For example, a run where an optional Dynamic Document step had no file shows:

Process Successfully Completed on 10/6/2026 9:14:31 AM
Error Encountered on Dynamic Document - Template # 8

If the field doesn't change at all after a background run, the request didn't start a run. Check the email notification, and check that the batch arguments include every required parameter. See Package Builder messages and troubleshooting.

The Run Details table

The installation wizard creates a table named Package Builder Run Details (alias [_DBID_PACKAGE_BUILDER_RUN_DETAILS]), related to the master table, and adds the rd parameters for it to both Package Builder fields. At the end of every run, including a run that stopped with an error, Package Builder adds one row for each step that ran. (From the button, the rows are written at the same moment as the status field, so if the window is closed early they may not be written, as described above.) The rows give you a history of runs for each master record.

Run Details parameters

Package Builder adds rows only when rddbid, rdrelfid, rdadnfid, and rdntsfid are all set. Leave all four out if you don't want run details. The wizard fills in the field IDs from your app, so the numbers in your formulas will differ from the samples.

In Package Builder Batch Arguments, write the same parameters with a leading space instead of &, for example & " rdrelfid=6".

Count documents (rdnumfid)

To record how many documents each step was asked to create, add a Numeric field to the Run Details table yourself, for example Documents Generated, and add rdnumfid with its field ID to both Package Builder fields. The wizard doesn't create this field or add this parameter.

Setting rdnumfid turns counting on. For each extension step, Package Builder reads the table and the record or query from the step's arguments (dbid and msid, msqry, or msqid), plus the step's apptoken, and counts the matching records. Static Document and Dynamic Document steps count as 1. In repository mode, PDF Merger steps also count as 1. In regular mode, a step whose count can't be read counts as 1. In repository mode, a step whose arguments are missing any of these values—including an empty apptoken=—stops the package; see Status field messages.

Note

The count is an estimate, not a check. It shows how many records the step was pointed at, and an extension may create fewer documents than that. Counting also adds Quickbase reads to every run, so use it only if you need it.

What a row looks like

For an extension step, Process Details holds three parts:

• Arguments for the process: followed by the step's arguments as Package Builder passed them to the extension, with double quotes removed.

• Process invoked at : and Process completed at : followed by the date and time the step started and finished, in our server's local time.

• TotalDuration for Process to complete: followed by the processor time the step used. This is usually shorter than the time between start and finish.

Static Document and Dynamic Document steps show Adding static page to package builder or Adding dynamic file to package builder instead.

Process Details shows what Package Builder ran, not why a step failed. The extension records its own reason separately; see A step failed: where that extension records why.

For example, the rows from one run of a four-step package in repository mode for project 25, with the optional Documents Generated field added:

Important

Process notes include each step's full arguments, so anyone who can see the Run Details table can read them. Keep passwords, keys, and other secrets out of the arguments fields. If a step's arguments must include an application token, limit who can view the Process Details field or the Run Details table with Quickbase role permissions.

Related articles

• Run a package from a button

• Run a package in the background

• Formula URL parameters

• Package Builder messages and troubleshooting