Skip to main content

Siteline + Foundation - SQL Server Permissions

Foundation tables that Siteline reads from and writes to

Written by Bradley LaFave

This page is intended for Foundation's support team — they provision the Siteline database user, including on on-premise installations. Include this list in your support ticket.

The Siteline user needs the listed permissions on each of the following Foundation objects. SELECT is read-only, INSERT and UPDATE are write access, and EXECUTE is permission to run a stored procedure. Granting just the columns we touch is not enough — SQL Server requires the listed permissions at the object level.

Ask for every object below in one request. Partial grants tend to cause confusing failures rather than clean errors — a project imports with no schedule of values, or a pay app fails to sync — and a second round-trip with Foundation support can add weeks to your go-live date.

Two objects are marked only if you have a general ledger split by division. Include them if you do; skip them if you don't, and everything else still works.

Object

Access

Name

Why Siteline needs it

accounts

SELECT

General Ledger Accounts

Reads your chart of accounts so you can pick the income, retainage, and A/R accounts each invoice posts to.

aia_header

SELECT

AIA Billing Header

Reads your AIA prime contracts — one per billing section — which become the projects you bill from in Siteline.

aia_item

SELECT

AIA Billing Items

Reads the schedule of values lines on each prime contract.

aia_item_history

SELECT

AIA Billing Item History

Reads previously billed and retained amounts per line so a new Siteline pay app picks up where Foundation left off.

ap_check

SELECT

AP Checks

Reads payments you have issued to vendors so Siteline can show payment status on lower-tier lien waivers.

ap_check_vch

SELECT

AP Check Vouchers

Reads how each vendor payment was applied across the invoices it paid, so Siteline knows which vendor invoices are settled.

ap_invoice_h

SELECT

AP Invoice Header

Reads invoices from your vendors, used on vendor-history and lower-tier waiver views.

ar_cash

SELECT

AR Cash Receipts

Reads customer payments you have received so Siteline can mark invoices paid automatically.

ar_cash_invoice

SELECT

AR Cash Receipt Applications

Reads how each customer payment was applied across the invoices it paid.

ar_invoice

SELECT, INSERT, UPDATE

AR Invoice Header

Creates the invoice in Foundation when you sync a pay app, and updates it if you re-sync. Invoices are written unposted — your team still reviews and posts them.

ar_invoice_gl

INSERT

AR Invoice GL Distribution

Writes the income-account entry that goes with each invoice Siteline creates.

control_ar

SELECT

AR Control Settings

Reads your company-wide default A/R account, so Siteline can use Foundation's default when an invoice does not specify one.

control_gl

SELECT

only if you have a general ledger split by division

GL Control Settings

Reads whether your general ledger is split by division and how your account numbers are laid out, so invoices post to the same divisional account Foundation would use.

cost_codes

SELECT

Cost Codes

Reads your cost codes so schedule of values lines can be coded consistently.

customers

SELECT

Customers

Reads your customers — name, billing address, and payment terms — so invoices bill the right party.

income_types

SELECT

Income Types

Reads your income types (revenue categories) so each synced invoice carries the right one.

job_chg

SELECT

Job Change Orders

Reads approved change orders so Siteline can pull contract adjustments into your schedule of values.

job_divisions

SELECT

only if you have a general ledger split by division

Job Divisions

Reads the division each job belongs to, so an invoice posts to that division even when the job has no schedule of values in Foundation.

job_history

SELECT

Job Cost History

Reads posted job costs so Siteline can show cost-to-date against each project.

jobs

SELECT

Jobs

Reads your jobs — the projects you select from when setting up billing in Siteline.

project_classes

SELECT

Project Classes

Reads your project class list so you can filter which jobs get imported into Siteline.

sales_taxes

SELECT

Sales Tax Codes

Reads your tax groups so taxable pay apps use the right one.

sales_taxes_rates

SELECT

Sales Tax Rates

Reads the state, local, and other rates behind each tax group so Siteline calculates tax the way Foundation does.

sp_GetNextNumber

EXECUTE

Next Number (stored procedure)

Foundation's own invoice-numbering routine — used when you choose to generate the invoice number from Foundation instead of entering it yourself.

terms

SELECT

Payment Terms

Reads your payment terms so each invoice gets the correct due date.

vendors

SELECT

Vendors

Reads your vendor list for managing sub-tier lien waivers and compliance requirements.

Notes

  • Invoice writes. ar_invoice and ar_invoice_gl are the only tables Siteline writes to. Invoices are written unposted — your team still reviews and posts them through Foundation's normal process, so nothing reaches your general ledger without your approval.

  • Invoice numbering. sp_GetNextNumber is only used when you choose to generate invoice numbers from Foundation rather than entering them in Siteline. next_number itself needs no grant: both objects are dbo-owned, so SQL Server's ownership chaining covers it.

  • Divisionalized general ledgers. If your income accounts are split by division (account 4010 in division 2 posting to 401002, say), grant control_gl and job_divisions as well. Siteline reads the division from the job itself, exactly as Foundation does, so invoices post to the right divisional account on every job — including jobs you bill without a schedule of values. Without those two grants invoices still sync, but they post with no division, and your team has to set it on each invoice in Foundation before posting. If your general ledger isn't divisionalized, skip them.

  • Verification. Siteline checks every entry on this page automatically once connected, and names the specific missing object if a grant was skipped. The two divisional objects above are reported separately as optional, so a skipped grant there doesn't read as a failure.

Did this answer your question?