- 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
Platform Services lets you extend 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 Intacct product help.
More detailed Platform Services developer information is coming to this space soon. Stay tuned!
Platform Services must be enabled by Intacct Customer Support. Once enabled, you can subscribe to it in your company by navigating to Company > Subscriptions. If you see Customization Services as a subscription, then Platform Services has not been enabled yet.
Make sure to verify that your contract (or your client’s contract) with Intacct includes this subscription.
Customization Services vs Platform Services
Customization Services lets you customize standard Intacct objects (Customer, Vendor, Account, AP Bill, and so forth). For example, you might want to add a field to the Location record to store the number of units in each property for a property management company.
Platform Services lets you extend the Intacct product by creating custom objects, pages, and applications. For example, a human resource manager might create an application that tracks employee benefit programs and integrates with employee information already in your system.
The same features in Customization Services are part of Platform Services, just in a different menu structure.
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, the Intacct system 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 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 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.
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 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 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 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 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.
Triggers provide a powerful way for you to automate tasks on 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 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 Intacct product help for usage information on document 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 Intacct product help for usage information on unique indexes.
Standard object pages
When Platform Services is enabled, pages of standard objects can be customized. This allows for new sections and tabs to be added to the add/edit/view object pages.
Tip: Standard object pages, even if included as part of a Platform Services application, will not be installed during the installation process. You would need to manually recreate those standard object pages in the application as part of your process.
Page scripts and stylesheets
Any attempts at using page scripts to manipulate Intacct’s standard DOM is discouraged and will not be supported. One such example would be using jQuery to find an 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 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
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 Intacct system is very similar to a merge field in your favorite word processing program.
The most basic merge field uses the 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:
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 Intacct system. For example, to access the integration names for VENDOR objects, open the Vendor Information page and choose More actions > Object definition. Integration names for custom objects are 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 in the Intacct system. 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 Intacct system. See the information about URLs to Intacct records in the Intacct product help to learn more.
For security reasons, the Intacct system cannot be placed inside an iframe by another web application. If you are attempting to access 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 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), 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 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. Do not put such information in the URL of a GET request.