|
|
Over the past few weeks we've been very busy wrapping up a large number of new platform features. Below are summaries of some of the more significant items we've deployed recently, although not a comprehensive list. Until we have time to update documentation and record a new set of Rollbase videos, please contact us if you need help diving into any of these features:
Sequential and Parellel Approval Processes
A new Approval object attribute enables you to create new Workflow Actions to invoke a sequential or parallel approval process for any record by triggering sequential emails to either the first assigned approver or all approvers on the list respectively. When an approval process is initiated on an object record you can optionally change the list of assigned approvers at runtime.
Only users who have been assigned the new "Approver" option can be added as approvers to any Workflow Action or record on the fly. In addition, by defining an appropriate number of Workflow Actions for approvals you can have predefined lists of approvers based on location, function, department, etc.
Online Surveys, Survey Recipients, Questions Library and Ranking
New
object attributes "Survey" and "Survey Taker" allow you to build
question and answer capabilities into any two related objects. For
example you may want to build customer survey functionality into your
custom Rollbase CRM application. To do this you might create:
- An object called Customer Survey with the new "Survey" attribute.
This attribute enables a "Questions" library for that object allowing
you to create any number of questions which can be attached to any
record to form a questionnaire. Each question's answer can be ranked to
assign kind of score or ranking to survey responses.
- An object called Customer Response with the new "Survey Taker" attribute. This
attribute enables a related Survey record's assigned list of questions
to be embedded in a portal or backend page where recipients can provide
answers to the questions.
Questions are like special kinds of fields whose values are designed
to be ranked and added to form an overall survey score. The following
Question types are currently supported:
- Checkbox
- Group of Checkboxes
- Currency
- Date
- Date/Time
- Email
- Integer
- Picklist
- Picklist (Multi-Select)
- Radio Buttons
- Text
- Text Area
- URL
Multi-Column Page Layouts
While the contents of any page Section can be organized in 1, 2 or 3-column layouts, up until recently Rollbase pages could only present Sections in a single column. Now in Generic pages you can specify whether to use a 1 or 2 column page layout. If a 2-column page layout is used each section can be placed in the left or right column, or you can choose to have a section span both columns.
To enable multi-column layout on any generic page:
1. Edit the page by clicking "Edit this page"
2. Click on the page title
3. In the Properties box change the new "Columns" property to 2
4. Now select any section and change the new "Alignment" property to Left, Right or Span
5. Notice that the page editor will update in real-time to show you a WYSIWYG layout preview
Tabs in View Pages
As your applications become more sophisticated, record view pages can become very long with large numbers of sections containing fields and many related lists below. To address this from a usability standpoint, now Pages can be organized into any number of tabs. You can create and manage page Tabs within the Page Editor, and easily move sections between tabs as well as re-order tabs as necessary.
To enable Tabs in any view page:
1. Edit the page by clicking "Edit this page"
2. Click on the page title
3. In the Properties box select the new "Enable Tabs" property
4. You will now see tabs at the top of the page. Click "Add Tab" to add as many tabs as you'd like
5. Click on any tab to go to that tab in the editor and use the Properties box to change the Tab label
6. Select any section and assign it to a new tab by changing its' "Tab" property
7. Notice that the page editor will update in real-time to show you a WYSIWYG preview
Posting Records to Portals
A new "Postable" attribute allows
you to define objects whose records can be "posted" to specific
portals. For example, you may have multiple portals representing
product catalogs. By enabling the "Postable" attribute you can choose
which portals each record should be shown on. In addition, in some
cases you can also specify which "New" form is used to respond to any
posted record. For example, you might select which request information
form should be used when a prospect wants more info on a product in one
of our catalog portals.
In addition, a new Workflow Event type called "Post/Unpost on Portal" allows you to control when certain records are posted to or taken down from specific portals based on any criteria and time delays you define.
Mass Upload (Import and Parse Documents)
Now any object with the Document as well as Contact and Location attributes provides a new menu called "Mass Upload". This new tool allows you to place any number of Word, RTF, PDF or TXT files into a queue and then upload them via AJAX. Rollbase will parse each document and create a new record by attaching the document and populating name, contact and location related fields with information gatherd from the document. You can watch the process take place in real-time through a dynamic user interface.
Unique Indexes
As you may already know, many fields provide an advanced property called "Do not allow duplicate values in this field". By enabling this property no two records of that object type can have the same value in this field. By enabling this on more than one field you can define significant duplication protection. However, until recently you could not combine fields together to form a more advanced dup validation mechanism.
Now each object definition has a new component called Unique Indexes. A Unique Index is basically a list of fields which form a combined value that cannot be duplicated and hence, prevent duplicate records from occurring. For example, if a Unique Index consists of fields X, Y and Z, then no two records can have the same values for X and Y and Z. However, for example, this does not prevent two records having the same values for X and Y but different values for Z. This is a very powerful new way to define duplicate prevention based on your specific application needs (you can even use Lookup fields to define unique indexes).
Dynamic View Filtering
You may have noticed a new "Filter" link associated with currently selected Views. This activates the filtering component directly above the View on the current page you are viewing allowing you to qucikly filter and refresh your selected View without having to switch to full View Edit model and committing yourself to any changes to your filter criteria. This same type of dynamic filtering is also available for Reports.
Detailed Search Component
A new Detailed Search component can now be embedded in any Generic pages in Portals as well as backend Pages. This component allows you to provide a small object-specific search form allowing users to locate records based on specific criteria relevant to the situation at hand. For example, you may place a Detailed Search comoneont in the home page of a product catalog portal to allow users to search for products based on price range, availability, type, brand, etc. Like other page sections, this component can be configured to display fields in 1, 2 or 3-column layouts. In addition, for each field chosen to appear in the component you can specify the operator used in the search such as "equals", "greater than", etc.
Grid Edit Component
Now you can create and edit related records in a dynamic grid component in any New and Edit pages. Simply drop the "Grid Edit" component into any New or Edit page and save your changes. Then click "Configure" to select which fields should be used as columns in the Grid.
Grid Edit allows you to create multiple related records at the same time you are creating a parent record. For example, when creating a Purchase Order you might use a Grid Edit component to add an arbitrary number of Line Item records associated with the PO you are creating. (We will cover this new component in more detail in a future post.)
Filter by Related Fields
In all Views, Charts, Reports and anywhere else you can filter data in Rollbase you can now also filter on related field values. For example, suppose you have a Customer object related to a Partner object and the Partner object has a User lookup field called Partner Owners. Now Rollbase will let you create a filtered Customers View filtered by Partner Owners. This seamingly small addition greatly broadens the ways data can be filtered in Rollbase.
Ability to Filter by Viewed/UnViewed and Flagged/Unflagged
Up until recently you could not search for or define filters to find or hide records that have been viewed, not viewed, flagged or not flagged. This is now available in the filter mechanism for Views, Charts, Reports and object-specific Search.
ZIP Code Radius Search
The object-specific search page for each Object with the "Location" attribute now includes a new ZIP code radius search capability allowing you to find records within a certain mile-based radius of any given US ZIP code. This can be useful for finding nearby leads, contacts, etc.
Global Portal Pages
All portal pages can now be shared among any number of portals. For example, you may want to use the same New Lead form in three different portals without having to duplicate it. Rollbase now allows you to assign portal pages to the specific group of portals you'd like to use them in.
Document Template based Reports
Rollbase now allows you to go beyond 1, 2 and 3 layer Tabular reports to build custom document (HTML, TXT Word and Excel) templates to be used for report generation. Using a robust set of merge fields including filterable functions such as SUM, COUNT, etc, Rollbase now provides a powerful mechanism for generating reports in a format specific to each customer's requirements. (We will cover this new functionality in more detail in a future post due to the extensive merge field options available and the virtually limitless display and formatting capabilities.)
As a Rollbase user you may have noticed that four new Object definitions have recently appeared in your account: Location, Department, Function and Group. In addition, as of last week a new Organization Management application has been published to the Application Directory to provide a simple way to manage these new features.
The Location, Department and Function objects are somewhat special new objects in Rollbase. Not only do they allow you full control over fields, pages, views, workflow, etc (as with any other object definition in Rollbase), they also come with special hierarchical view components providing an easy way to visualize the structure of any sized organization -- whether you are managing a small business are a global company with over 10,000 employees.
By enabling the new "Organization" attribute in any of your object definitions, you can assign data records to specific positions in any of these hierarchies. This in turn determines who can access these records based on what Groups your users are assigned to.
The Group object is also a new object definition with some unique capabilities, the most important of which is its capability to restrict specific portions of the Location, Department and Function hierarchies that a set of users can have access to.
For example you might create different Groups for Sales Managers in US, Canada, APAC, EMEA, etc. While users assigned to these Groups may have the same Role and User-specific permissions, they will only be able to access data associated with different portions of the hierarchies based on their Group asignments.
Each user can be assigned to any number of Groups (you will now see a new "Groups" picklist associated with your User object definition for this purpose). In this way you can model complex organizational structures and leverage these structures to segment data access for tens, hundreds and even thousands of users in an intuitive, scalable, and easy to manage way. The below screenshot shows an example hierarchy of Functions in a fictitious organization:
It is helpful to think of Groups as a way to restrict access to any Rollbase data for a particular set of users before any Role and User specific permissions are applied. With these additions there are now several layers of permission management available to enable very simple as well as more sophisticated, larger-scale Rollbase implementations.
All of this functionality is now available to every Rollbase user and has been automatically added to your account using our new Managed Applications capabilities. For any users wishing to explore this further, we recommend installing the Organization Management application into your account.
In Part 1 we summarized the basic components of Rollbase Objects and in Part 2 we took a quick look at Fields which are the primary building block of Objects. Beyond fields the most important Object components are Relationships.
Relationships are established between two objects as a way to connect different types of data in your applications. For example, lets say we're building an application to create Quotes which consist of Quote Line Items, where each Quote Line Item is associated with a specific Product. In this example a Quote object is related to a Quote Line Item object, and the Quote Line Item object is related to a Product object. Since each Quote has many Quote Line Items, we say there is a "One to Many" relationship between the Quote and Quote Line Item objects. Similarly, since each Quote Line Item only has one Product associated with it, but each Product can be used in any number of Quote Line Items, there is a "Many to One" relationship between Quote Line Item and Product.
Note: This "One to Many", "Many to One", "One to One", or "Many to Many" terminology is referred to as the Cardinality of the relationship.
By creating relationships between objects in Rollbase you can rapidly model sophisticated business applications with simple or complex interdependencies. Once a relationship is established, information about that relationship can be used to customize pages, views, templates, charts, reports and many other application components based on your application's needs. For example, in the screenshot below we're showing a Quote View page with a Related View component displaying all of the Quote Line Items associated with a particular quote record via a relationship. This Related View also demonstrates how each Quote Line Item is displaying information about related Product records here and we are able to execute formula-based calculations on fields from multiple related objects.
As another example, below we are showing a spreadsheet generated from a Document Template associated with the Quote object. This template was constructed from merge fields using Quote fields and fields from the related Quote Line Item object definition, as well as fields from other objects such as Customer and Account.
We will discuss Document Templates in a future post, but suffice it to say here, like many other object components they allow us to loop through related items and use information about each item to generate an appropriate result -- in this case an Excel Spreadsheet showing all line items, subtotals, totals, etc. A similar output could be just as easily generated in the form of a Word document or rich HTML email. None of this would be possible without Relationships.
When creating a relationship in Rollbase you are first presented with a list of object definitions to choose from. Choose the object you want to establish a relationship with (don't worry about the complex implications of creating multiple relationships between the same objects, Rollbase will handle this for you under the covers). Once you select the target object you'll need to specify whether the relationship is a Simple Relationship or a Complex Relationship.
Simple Relationships
Simple relationships are direct relationships between two objects. For example a simple relationship created between object A and object B means that records of type A can directly reference records of type B and vice versa.
When defining a new Simple relationship you must define relationship properties, cardinality, orphan records control and cloning control settings (discussed below). Relationship properties require you to assign singular and plural names for each side of the relationship, as well as a unique integration name. For example, if you are creating a relationship between Quote and User objects, you might use “Owner” and “Owners” to represent the user side of the relationship.
Relationship cardinality determines whether records of each type can have one or more than one related record. You can select One-to-One, One-to-Many, Many-to-One, Many-to-Many.
Complex Relationships
Complex relationships are used in cases where information about the relationship itself is required to be stored and managed. In our example above, a Quote Line Item essentially represents a complex relationship between Quote and Product objects in order to manage relationship data such as Quantity.
When you create a complex relationship a new object definition is automatically created to represent the relationship between the source and target objects. Simple relationships are then created between the source object and the intermediate object, and between the intermediate object and the target object. In this way you can create fields and other components in the intermediate object to store as much information about the relationship as you need.
Orphan Records Control
Orphan records control allows you to specify whether or not related records get deleted whenever a parent record is deleted. For example if we delete a Quote we might also want to delete all of the related Quote Line Item records as well. But the opposite case is not true, that is if we delete a Quote Line Item we do not want to delete the related Quote record. Rollbase allows you to control this kind of behavior for each relationship.
Cloning Control
Cloning control allows you to specify whether or not related records get cloned whenever the parent record is cloned. For example if we clone a Quote we might also want to clone all of the related Quote Line Item records as well. But the opposite case is not true, that is if we clone a Quote Line Item we do not want to clone the related Quote record. Rollbase allows you to control this kind of behavior for each relationship.
Lookup Fields
When creating a new relationship Rollbase will also create Lookup fields and Related View components for each object. Lookup fields are used to select one or more related object records when editing or creating a new record.
By default Lookup fields allow you to pick one or more records by displaying a Selector Page in a popup (we will discuss selector Pages and popups in a future post). However, often times it is faster and more convenient to allow users to select records using a picklist or multi-select picklist. Rollbase allows you to change whether a Lookup field displays as a popup selector or a picklist/multi-select picklist via a page level property.
Related Views
Related Views are used to display a list of related records for objects with One-to-Many or Many-to-Many relationships. For example, the Quote View page shown in the beginning of this post contains a Related View component that displays all related Quote Line Item records. Related Views are identical to View components only they are inherently filtered by the relationship established between the object record being viewed and its related records (we will discuss Views and Related Views in more detail in a future post).
Although we have only presented a few small examples of how Relationships can be used here, they are a critical component of almost every Rollbase application you will install or buld and are pre-requisites for many advanced features such as Multi-layer Reporting, Workflow Event Conditions, Formula Fields, Templates, etc. Stay tuned for Part 4 where we will introduce Object Pages and the Rollbase Page Editor.
In Part 1 we introduced Rollbase applications and took a brief look at Objects and their components, where we described Fields as follows:
Fields are the basic building block of object definitions. Objects can have an arbitrary number of fields associated with them. Fields are used in Pages, Views, Charts and other object components to display and input object data. Fields determine what kind of data is stored with each object record. If you think of an object definition kind of like a spreadsheet or a database table, a field is analogous to a column.
For example, a Product object might have fields for Name, Description, Unit Price, Model #, etc. When defining Objects in Rollbase one of the first things you need to do is think about all of the fields you need to create for that Object along with the type of data each field needs to store.
Rollbase allows you to pick from up to 25 different types when creating your fields. In the above example Unit Price might be a Currency field and Model # might be a Text Field.
STANDARD FIELD TYPES
- Checkbox: Users can select a Checked (true) or Unchecked (false) value.
- Currency: Users can enter a dollar or other currency amount.
- Date: Users can enter a date or pick a date from a calendar popup.
- Date/Time: Users can enter a date and a time, or pick a date from a calendar popup (when a date is selected from the calendar popup, that date and the current time are entered into the Date/Time field).
- Decimal: Users can enter any number including decimals. You can optionally define a maximum number of decimal places.
- Email: Users can enter an email address which is checked to ensure that it is a valid format.
- Integer: Users can enter any number (without decimals).
- Percent: Users can enter a percentage number including decimals, % sign is automatically added.
- Picklist: Users can select a value from a list of values defined by you.
- Picklist (Multi-Select): Users can select any number of values from a list of values defined by you.
- Text: Users can enter any combination of characters. You can optionally define an input mask to enforce certain kinds of input.
- Text Area: Users can enter multiple lines of text (you can set a maximum limit of up to 32,000 characters). You can optionally enable a rich text editor so users can enter text as formatted HTML.
- URL: Users can enter any website address.
ADVANCED FIELD TYPES
- Auto-Number: An automatically generated sequential number or code that uses a display format defined by you. This number is incremented for each new record created.
- File: Users can upload a file which can be accessible through this field, and optionally indexed as part of the search engine. You can specify a maximum size for files from 128KB up to 2MB.
- Image: Users can upload an image which will be accessible through this field. You can specify a maximum size for images from 128KB up to 2MB.
- Shared Image: You can upload an image to be shared as a merge field in any object pages and templates. Shared images are also stored and distributed with published applications.
- Formula: A non-editable field that is automatically populated from a formula expression defined by you. A formula field is automatically updated when any of the fields used in the expression change value.
- Template: A non-editable text field that is automatically populated from a template expression defined by you.
- Document Template: A link which generates a document on the fly using a pre-defined document template (Word, Excel, Text, HTML, etc)
- Related Field: Value of a field from a related object
- Integration Link: A custom link to integrate Rollbase data with external URLs, your intranet, or other systems.
PORTAL-SPECIFIC FIELD TYPES
- Captcha Image: Require that the user type the letters of a distorted image to ensure that the user is in fact a human rather than a computer. Form submission will not work if the entry is not correct.
- Hidden Input: Capture a parameters from the original URL such as a campaign id, source name or keyword.
- IP Address: Capture and resolve the IP address of portal visitors.
Each field has a set of properties and advanced properties associated with it that affect global field behavior. For example when creating a field of type Currency, the following properties are available:
Based on the field's type you will see a different set of properties and available advanced properties. For example, many fields allow you to "Index this field as part of the text search engine," which tells Rollbase to make this part of the global search engine (we will discuss searching in more detail in a future post). You can also "Track all changes to this field in each record's Audit Trail for a complete historical log." This is particularly useful for compliance purposes such as SOX, HIPPA, etc.
Fields also have a few other properties such as description and integration name which is used as a unique way to reference the field in Templates, Formulas, Merge Fields, and via Rollbase Web APIs.
Once a field is created it can be added to any object and portal Pages and it will be displayed as expected based on the field's type. For example when added to any form pages a Currency field will be displayed as a text box that only allows input of a valid currency value. Rollbase enforces valid field values via server-side validation.
Fields can be created manually when working with Object definitions in the Rollbase Setup area, or they can be created on the fly from within the Rollbase Page Editor (dynamic field creation from within the page editor is a recently completed feature we will be covering in an upcoming post).
Each field's global properties will be enforced at the individual page level. However, you can also apply page-specific properties to fields from within the editor to affect local field behavior on that page only. For example, page-specific properties for a Text Area field include Required and Read Only as well as Rows and Columns allowing you to dynamically change its size on that page.
Beyond Pages, fields are used in Views, Charts, Reports, Advanced Search, Templates, Portals, HTML and Script components, and many other places throughout Rollbase. Understanding fields and their numerous uses in your applications sets the stage for building objects with capabilities to manage virtually any kind of business data.
Stay tuned for Part 3 where we will introduce Object Relationships, the fundamental links between Objects that are required for building sophisticated business applications in Rollbase.
"What is a Rollbase Application?" This is one of the questions new users grapple with right away and we are always on the lookout for better ways to help guide you to the answer faster.
Today we posted a first draft of The Rollbase User Guide (PDF 1.8MB). Although this is the first iteration it contains 87 pages of material designed to help answer the most basic questions regarding all major areas of the platform. While this guide is a good reference for serious Rollbase users, we don't expect you to read 87 pages just to find out what a Rollbase application is. So we've put together a few excerpts here to help with this fundamental question. This is Part 1 in a series of posts we will publish on this topic:
What is a Rollbase Application?
Rollbase applications consist of a set of configurable components combined together to form a working application. The core components of an application are Objects, Tabs and Portals. Similarly, each of these core components consists of their own sets of configurable sub-components. The diagram below illustrates.
The process of creating an application in Rollbase involves defining core components and then building them out by adding and configuring their sub-components.
Objects
Objects, or Object definitions as they are often referred to, are the basic building block of all Rollbase applications. You can define Objects to represent any kind of business data such as a Customer, Employee, Product, Quote, Invoice, Purchase Order, Partner, Project, Meeting, Conference, Bug, Rating, Comment, Support Request, Help Ticket, Asset, etc.
You can think of an Object definition as a template for what actual instances of that object should look like, sort of like a cookie cutter or mold that defines the overall shape and contours of the end product. (If you are an Object Oriented programmer, you can think of object definitions as Classes.)
Object records are actual instances of Object definitions. For example, if you have defined an object called Employee, each object record would represent an actual employee in your company. Object records are, for all intents and purposes, rows of data in your Rollbase database. You can create as many object records as you want up to the record limit in your account.
As you can see from the diagram above Objects have an array of sub-components that are used to build out the object definition. We will introduce each object component type here and discuss them individually in more detail in future blog posts. Objects also have a number of Properties and Attributes, which are important to determining object record behavior and capabilities; this too will be covered in more detail in a later post (or you can check out the User Guide now).
Object Components
- Fields: Fields are the basic building block of object definitions. Objects can have an arbitrary number of fields associated with them. Fields are used in Pages, Views, Charts and other object components to display and input object data. Fields determine what kind of data is stored with each object record. If you think of an object definition kind of like a spreadsheet or a database table, a field is analogous to a column.
- Relationships: In order to build sophisticated business applications you need a way to establish relationships between objects. For example, an application that allows the creation of Invoices would typically have Invoice and Invoice Line Item objects that are related in that one Invoice can have any number of Invoice Line Items associated with it. Rollbase allows you to create any number of relationships between any number of objects.
- Pages: Each object definition comes with a set of pages used to display and input object data in various ways. When an Object is created it automatically has a set of pages associated with it for viewing, creating, editing, searching, selecting, navigating, and many other purposes. You can edit each page using drag & drop with the Rollbase Page Editor, and clone pages to create multiple different versions. You can also create entirely new pages as needed. Without full control of all object pages, your applications would be extremely limited.
- Views: Views show a subset of all object records sorted and displayed in a particular way. For example, for an Assets object, perhaps you only wish to display the Laptop records. To do that you would create a Laptops View designed to only show the appropriate records. Views display a list of object records that you can navigate, sort, and perform actions on in real-time. Each object definition can have an arbitrary number of Views associated with it and users can switch to any other available View as needed.
- Email Templates: Email Templates are designed to send personalized messages rapidly to individuals and multiple recipients. They can be defined in HTML or plain text format, and can incorporate field data from object records as well as related records.
- Document Templates: Document Templates are designed to generate personalized documents rapidly. They can be defined in Word (.doc), Word 2007 (.docx), Excel (XLS or CSV), Excel 2007 (.xlsx), HTML or plain text formats, and can incorporate field data from object records as well as related records. (Pending: support for .docx and .xlsx is in progress)
- Reports: Reports allow you to create a more specific view of a set of object records and related records in order to narrow in on specific data you are looking for at any given time. (Pending: development of multi-level reporting is in progress) Reports allow you to report on record data up to three levels deep. For example if you have a Patient object related to Bills and Bills related to Payments you might create a report that shows you all overdue Payments for unpaid Bills associated with Patients who had appointments in the past 30 days.
- Charts: A chart in Rollbase is a type of information graphic that represents tabular text or numeric data. Some charts can be animated and offer interactive capabilities such as rotation or switching between 2D and 3D modes. You can create any number of Charts to represent your object record data in a variety of ways. Like Views, users can switch among available Charts in real-time.
- Workflow Statuses: Rollbase provides an easy way to create state-based workflows for object definitions. Workflow Statuses represent different stages or steps in this workflow. For example, a Purchase Order object might have Statuses for Created, Submitted for Approval, In Process, Approved, and Rejected. Workflow Statuses are used in combination with Workflow Actions and Events.
- Workflow Actions: Workflow Actions are links users can click to either move an object record to another Workflow Status, or create a new related record. In our Purchase Order example above, there would also be Workflow Actions for Created, Submitted for Approval, In Process, Approved, and Rejected that are used to move records to those Statuses. When an action is performed on a record, it may trigger a Workflow Event.
- Workflow Events: Workflow Events offer powerful automated workflow capabilities and business rules. Events have a trigger that determines when the event should be fired, and a type that determines what kind of action the event should perform. Events also have a condition formula allowing you to build detailed rules into each event to determine whether or not to fire the event based on various criteria. Workflow Events can be used to automatically send an email, change a field value, and much more.
- Conversion Maps: Conversion maps make it easy to move data between any of your Rollbase applications. They are used to define how object records can be converted from one object type into another. Conversion maps can be saved and reused in workflow events or manually when users invoke the Convert action on one or more records. For example, using Conversion Maps you can easily define how a Lead record should be converted into a Customer record, or how a Support Request record should be converted into a Case or Bug.
"The whole is greater than the sum its parts" is a perfect old adage for Objects. The evidence of this is in the growing library of full-featured applications available in the Rollbase Application Directory today for everything from CRM to Order Management to an evolving suite of integrated Human Resources applications. Stay tuned for the next installment where we'll take an in-depth look at Object Fields.
|
