- Customization Services vs Platform Services
- Custom objects
- Standard object pages
- Page scripts and stylesheets
- Conditions and formulas
- Merge fields
- Integration names for standard and custom fields
- URL parameters and record URLs
- Application framing
- Content security policy (CSP)
- Sensitive information
- Troubleshooting and FAQs
- What’s next?
Platform Services lets you extend Sage Intacct by creating your own custom objects and applications.
These extensions include:
- Custom objects
- Customization Services
This topic provides an overview of Platform Services features for developers. Usage information about Customization and Platform Services in available in the Sage Intacct product help.
Platform Services must be enabled by Sage Intacct Customer Support. Once enabled, you can subscribe to it in your company by navigating to Company > Admin > Subscriptions. If you see Customization Services as a subscription, then Platform Services has not been enabled yet.
Note: Make sure to verify that your contract (or your client’s contract) with Sage Intacct includes this subscription.
Customization Services vs Platform Services
Customization Services lets you customize standard Sage Intacct objects (Customer, Vendor, Account, AP Bill, and so forth). For example, a property management company might want to add a field to the Location record to store the number of units in each building.
Platform Services lets you extend the Sage Intacct product by creating custom objects, pages, and applications. For example, a human resource manager might want an application to track employee benefit programs and integrate with employee information already in the system.
Platform Services includes all the features in Customization Services.
Depending on whether you subscribe to Customization Services or Platform Services, you will use a different approach to access features.
An application is a wrapper around a group of custom objects, standard objects, and menus that work together as a solution. An application can be published (as an XML file) and installed on target machines.
When you create or install a custom application, Sage Intacct adds an entry for that application to the navigation menus. It also adds the application to your subscriptions and permissions pages. You can set user permissions for the application just as you would for a standard Sage Intacct application.
Managed applications are recommended as a best practice if you are a partner writing a solution utilizing Platform Services. Your customer’s administrator can easily install the application file, which means that you do not need administrative access to their Sage Intacct company. Because it is a managed application, the installed version cannot be altered.
Once an application is installed, any upgrades must be done manually—there is no system-wide push.
Important: If you have standard object customizations, these standard objects should be included with your platform application. You should not have a separate customization package and a platform application installer as this will cause future upgrade problems.
At the basic level, custom objects are like database tables that you can manage visually—the columns are the object’s fields and the rows are the individual records. Custom objects are the basic building blocks of all Sage Intacct applications. When creating custom objects, you can use components that define how the system manages and processes the data records in the object. Components include items such as fields, relationships, pages, triggers, document templates, and unique indexes.
See the Sage Intacct product help for usage information on custom objects.
Fields define the attributes of an object, and records are instances of the object. There are many different field types available on custom objects. Keep in mind that the field types for custom objects are not the same as the field types for standard objects.
Relationships define the connections between records in different objects. Just as objects are the backbone of a platform application, much of the functionality within objects comes as a result of relationships. You set up the relationship types in Sage Intacct as either one-to-one, one-to-many, many-to-one, or many-to-many.
An object can only access a related object field value one step away. If you need to get a value from an object two steps away, you need to create a related field in an adjacent (one step away) object and reference the value from there.
Before creating any relationships, make sure:
- You understand what the standard object really is
- You know that the typical user will benefit from the addition of that relationship
See the Sage Intacct product help for usage information on relationships.
Pages are the user interface for your application. When an object is created, a group of default pages is created for it. These default pages cannot be deleted, but they can be edited. You can create new pages of the same type by cloning an existing page, which ensures that you get a working page as a starting point. You then use page selection formulas to display your page when needed.
See the Sage Intacct product help for usage information on pages.
Platform Triggers provide a powerful way for you to automate tasks on both standard and custom objects. They are designed to lighten your workload while maintaining consistent results by automatically applying input, output, update, validations, emails, and API calls in response to data changes. Any time you have a regular event related to changes in object records, you can add the event to your application in the form of a trigger.
See the Sage Intacct product help for usage information on triggers.
Document Templates exist primarily for use with Web Services (API) calls made via Platform Services. A Document Template is usually an XML document with merge fields from the object in scope and from related objects.
See the Sage Intacct product help for usage information on templates.
Unique indexes let you maintain data integrity by preventing duplicate data. When you create a unique index, you establish a rule that prevents the creation of records with the same value(s) for the given field(s). A unique index can apply to any field or combination of fields. For multiple fields, the exclusion is based on an AND operation—the complete set of field values must match for the exclusion to apply.
Using a unique index on the
name field of a custom object is a recommended best practice. This is especially important for objects set up as user-defined dimensions.
See the Sage Intacct product help for usage information on unique indexes.
Your application can include user-defined dimensions (UDDs), which are simply custom objects that are enabled as user-defined GL dimensions. UDDs are available on reports and transaction entry pages—See the Sage Intacct product help for information about creating dimensions.
Before deciding to provide a UDD with your application, be aware of the following:
- There may be an associated cost for the company installing the application
- UDDs cannot be uninstalled after they are in use
- Transaction and report processing times can increase as UDDs are added
To make sure that the consumer of the application is aware of these considerations, an administrator with the appropriate permissions must authorize the installation of an application with UDDs.
Important: Administrators cannot grant themselves permission to authorize the installation of applications with UDDs. Rather, an administrator is granted this permission by another administrator. (If there is only one active administrator in the company, an exception is made to this rule.) An organization might typically designate one administrator and one backup with this permission.
When you publish an application with UDDs, you can generate an email authorization request to send to the appropriate administrator. If someone attempts to install the application before it has been authorized, the installation issues an error. See the Sage Intacct product help for information about custom applications.
Standard object pages
When Platform Services is enabled, pages of standard objects can be customized. This means you can add new sections and tabs to the add/edit/view object pages. Changes to standard object pages are installed as part of any application published after 2019-R1.
You can tell that an application XML file supports this feature by verifying that it includes the following tag:
Important: Include your standard object customizations with your platform application. Do not provide a separate customization package as this will cause future upgrade problems.
Page scripts and stylesheets
Any attempts at using page scripts to manipulate Sage Intacct’s standard DOM is discouraged and will not be supported. One such example would be using jQuery to find a Sage Intacct standard field by its ID and then hide it in the user interface.
In order to use Platform Services, you must be a full administrator in the Sage Intacct company you plan to extend.
It’s considered a best practice to add a namespace to the integration name fields of your extensions. This helps avoid name conflicts with other extensions, particularly those from partners. Keep the namespace short.
For example, My Expense Integration would prefix its custom object integration name with
Conditions and formulas
See the Sage Intacct product help for usage information on formulas.
Merge fields, which are similar to injections in Customization Services, are available for use in a variety of the extensions across Platform Services. A merge field in the Sage Intacct UI is very similar to a merge field in your favorite word processing program.
The most basic merge field starts with the Platform Services ID of the current object being extended, followed by a period, followed by the ID of the field within that object. The
!} characters are used as opener and closer characters respectively:
Note that the Platform Services IDs for objects and fields are also know as their integration names.
Integration names for standard and custom fields
The integration names for standard and custom fields can be found in the object definition of the given object in the Sage Intacct UI. For example, to access the integration names for VENDOR objects, choose Platform Services > Objects > Vendor. Integration names for custom objects are also found in the object definitions within your platform application.
URL parameters and record URLs
You may have noticed certain parameters, like
.noframeset=, in the URL bar when using the Sage Intacct UI. These parameters can change during any release and will be removed at a future date—do not try to build your own intacct.com URLs. The record URL field found on many standard and custom objects is the only supported way of linking to pages in the system. See the information about URLs to Sage Intacct records in the Sage Intacct product help to learn more.
For security reasons, Sage Intacct pages cannot be placed inside an iframe by another web application. If you are attempting to access Sage Intacct from a page on another site, simply display it in a new browser tab or window.
Through Smart Link fetches and Platform Services integrated link fields, you can display another site in an iframe inside Sage Intacct (provided that site allows it). However, this is not recommended unless you control the site.
Content security policy (CSP)
As one layer of defense against cross site scripting (XSS), Sage Intacct employs CSP across all pages in the UI. If you have page scripts referencing external resources, you must add these domains to one of:
- The individual page CSP
- The application’s overall CSP (making sure the object is included with the app)
- The company’s CSP
No developers should store sensitive information within Platform Services objects, custom fields, pages, URLs, and so forth. This applies especially to Web Services credentials, user credentials, session IDs, and credit card/bank account info.
All outbound traffic from scripts, triggers, or Smart Events should be done using HTTPS. The target URL must have a valid SSL certificate or Sage Intacct will fail the request.
Any information (such as session IDs) that is passed externally should be sent in the body of a POST request.
Troubleshooting and FAQs
See the FAQs for Platform Services.