Before you start
The connector reads BuildMate with the e-mail and password of a BuildMate user, the same login used in the BuildMate app. The data it extracts is what that user sees:- only the cost centers the user has access to (a main administrator sees all of them);
- only the modules enabled for the user and the company (for example, the PPE streams need the PPE module and the tool streams need the tools module).
Configuring BuildMate as a Source
In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the BuildMate option from the list of connectors. Click Next and you’ll be prompted to add your access.1. Add account access
The following configurations are available:- E-mail: The e-mail of the BuildMate user.
- Password: The password of that user.
- Cost center IDs: (Advanced, optional) Read only these cost centers, by their BuildMate ID or their Sienge code (for example
101). Leave it empty to read every cost center the user can access. A value that matches no cost center the user can access makes the run fail with that value in the log.
2. Select streams
Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis.Tip: The stream can be found more easily by typing its name.Select the streams and click Next.
3. Configure data streams
Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.- Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
- Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
- Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
- Sync Type: every BuildMate stream is FULL_TABLE. BuildMate does not let the connector ask only for what changed, and records change after they are created (a requisition is approved, a PPE item is returned, a unit goes to maintenance), so each run reads the current state of everything.
4. Configure data source
Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. A daily run is usually enough. Each run opens every requisition and every inventory to read their lines (about 17 extra minutes per 10,000 requisitions), so it takes longer on accounts with many requisitions. Optionally, you can define some additional settings:- Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
- An Additional Full Sync is not needed: every run is already a full read.
5. Check your new source
You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.Streams and Fields
Available streams
The table below lists every stream, its slug (the exact identifier to pass when creating the source via API) and a short description.
Small nested objects are split into their own columns (for example
cost_center_name). Lists that are not a stream of their own are stored as JSON text, for example json_extract_scalar(nfs, '$[0].number'). Money and quantities are decimal numbers.
Products: BuildMate returns the supplies with stock, plus the supplies at or below a configured minimum stock (including those at zero). A supply with zero stock and no minimum stock is not returned by BuildMate, so it leaves the
products table.Current lists:
kits has only active kits, and epi_pending_returns only items not yet returned. When a kit is replaced by a new version or an item is returned, it leaves those tables on the next run. Requisition lines keep the kit ID and name, and epi_delivery_items keeps the return data.Cost centers the user cannot open: in the streams read per cost center (
purchase_order_items, tool_units, tool_usage_history), a cost center where the user has no access to that data is skipped, and the run log names the skipped cost centers; their rows are not in that table. If the user has no access in any cost center, or BuildMate refuses a stream for another reason (for example a module the company does not have), that stream fails with BuildMate’s message in the run log and the other streams are still extracted.If a list cannot be read consistently after a few attempts, or BuildMate returns an unexpected response, the stream fails instead of saving a partial table. A requisition or inventory deleted while the sync runs is skipped with a warning.Fields by stream
Cost centers
Cost centers
Stream name:
cost_centers. One row per cost center (construction site) the user can access.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Products (supplies)
Products (supplies)
Stream name:
products. One row per supply of a cost center, with stock, costs and ABC curve.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Kits
Kits
Stream name:
kits. One row per active kit.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Kit products
Kit products
Stream name:
kit_products. One row per supply in a kit.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
kit_id,line_key
Requisitions
Requisitions
Stream name:
orders. One row per requisition, of every status.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Requisition items
Requisition items
Stream name:
order_items. One row per line of a requisition: loose supplies and the supplies of its kits.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
order_id,line_key
Tasks (apropriações)
Tasks (apropriações)
Stream name:
tasks. One row per budget task synced from Sienge.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Task appropriations
Task appropriations
Stream name:
task_appropriations. One row per supply appropriated to a task.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Inventories
Inventories
Stream name:
inventories. One row per inventory (stock count).Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Inventory items
Inventory items
Stream name:
inventory_items. One row per item counted in an inventory.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
inventory_report_id,id
Purchase order items
Purchase order items
Stream name:
purchase_order_items. One row per purchase-order item synced from Sienge.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
PPE deliveries
PPE deliveries
Stream name:
epi_deliveries. One row per PPE delivery sheet.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
PPE delivery items
PPE delivery items
Stream name:
epi_delivery_items. One row per PPE item delivered.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
PPE pending returns
PPE pending returns
Stream name:
epi_pending_returns. One row per PPE item that must be returned and was not yet.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
PPE trainings
PPE trainings
Stream name:
epi_trainings. One row per training.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
PPE training participants
PPE training participants
Stream name:
epi_training_participants. One row per participant of a training.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
PPE training types
PPE training types
Stream name:
epi_training_type_options. One row per training type of the company.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
PPE matrices
PPE matrices
Stream name:
epi_matrices. One row per PPE matrix (PPE required by a job function).Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
PPE matrix items
PPE matrix items
Stream name:
epi_matrix_items. One row per PPE required by a matrix.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Tool models
Tool models
Stream name:
tool_models. One row per tool or equipment model.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Tool units
Tool units
Stream name:
tool_units. One row per physical tool or equipment unit.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Tool suppliers
Tool suppliers
Stream name:
tool_suppliers. One row per tool supplier.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Tool usage history
Tool usage history
Stream name:
tool_usage_history. One row per delivery or return of a tool unit.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id
Tool maintenance history
Tool maintenance history
Stream name:
tool_maintenance_history. One row per tool movement that went through maintenance.Sync Strategy:- Full table (every run reads the current state)
- Primary key(s):
id