A customer relationship management system can hold far more useful information than names, email addresses and sales opportunities. An insurance broker may need to understand several policies associated with one client. A service company may need to track equipment, warranties and renewal dates separately from the contact who requested the work. A project consultancy may need a record of contracts, milestones and service obligations without turning every detail into an additional contact field. Custom tables provide a way to store those related records alongside the CRM relationship.<\/p>\n
Act! Custom Tables are designed for this kind of structured business information. They can extend what an organization records about customers and connect operational details to its existing CRM activity. The decision to use them should start with a data model, user permissions and concrete reporting requirements, not the assumption that adding tables automatically creates a complete business system or a working automation. Act! product editions, feature availability and subscriptions also matter; check the organization’s current configuration before designing a workflow around a feature.<\/p>\n
A contact record describes a person or an organization. A policy, service agreement, property, asset or recurring engagement is a different kind of entity, often with its own status, owner, dates, monetary values and supporting documents. If a customer has ten policies, adding ten sets of "policy 1" through "policy 10" fields to the contact is difficult to maintain and report on. A related custom table can represent each policy as its own record while retaining the customer relationship.<\/p>\n
Start by listing the entities and the questions users must answer. An account manager may need to ask which service contracts expire next month, which contacts have an open issue, or which assets are approaching the end of their warranty. Define the smallest set of fields that answers those questions. Choose stable identifiers, required fields, permitted values, date formats and ownership rules before importing any real records.<\/p>\n
Do not treat every business concept as a new table. A reportable status or customer category may be a field on an existing record; a repeatedly occurring item with its own lifecycle may justify a separate table. The distinction affects data quality, navigation and how easily employees can update the right information. Plan for duplicate contacts and changes in ownership rather than assuming a single email address permanently identifies one customer.<\/p>\n
Act!’s Custom Tables feature supports industry-specific information such as policies, service contracts, mortgages and projects, with data visible in CRM contexts rather than isolated spreadsheets. The practical value comes from displaying the right related record when an employee is already working with the customer. A service representative can see the serial number and warranty expiry associated with an inquiry; an account manager can prepare a renewal conversation using the actual contract record.<\/p>\n
A useful implementation should make the relationship between the custom record and the contact unambiguous. In a professional-services firm, a project table might include a project identifier, scope, primary client, milestone dates and current status. If a project has several stakeholders, decide how those people are represented and who can change the main project record. Poor relationship design can create duplicate activity histories even when each individual field looks correct.<\/p>\n
An interface that shows contextual data can reduce manual searching, but visibility does not ensure the information is current. Decide where each field is maintained and how updates from other systems are reconciled. When two systems both claim to own a contract status, staff need an explicit conflict rule; otherwise the CRM becomes another place to store conflicting answers.<\/p>\n
An insurance team could store policy number, line of coverage, renewal date, insurer and assigned account manager. A real estate team might store property identifier, location, listing stage, associated contacts and next scheduled task. A support business may keep installation date, service tier, device model and warranty end date. These are illustrations of data modeling, not proof that Act! automatically handles underwriting, claims adjudication, real-estate compliance, or service dispatch.<\/p>\n
Custom records are particularly useful when dates and statuses connect to human follow-up. For example, a manager can filter contracts whose renewal date is approaching and create or assign work through a documented process. Automatic reminders and external workflows require the relevant product features, permissions and configuration; they should not be presumed from the existence of a table. Test the actual scenario and verify that a missed reminder has an observable failure path.<\/p>\n
Industry-specific templates can accelerate field design, but a template cannot determine an organization’s legal retention obligations or data classification. Healthcare, insurance and financial-service teams should carefully assess whether the proposed custom table is an appropriate place to store regulated information. Store only the data necessary for the approved process and apply the access and retention rules that govern it.<\/p>\n
A table is useful only when its records mean the same thing to different users. Define whether a field accepts free text, a controlled choice, a date, a number or a reference to another record. A date should not be stored as a paragraph because later sorting and filtering become unreliable. A status such as Act! provides tools for managing custom-table fields, including choosing field types and applying field-level security in supported editions. These controls should be tested with real user roles. An account manager may be allowed to see a renewal date without being allowed to edit a financial value; a temporary contractor may need access to selected project fields but not full customer history. Do not assume that a screen hiding a field proves the underlying API or export permissions are equally restrictive.<\/p>\n Data migration deserves its own validation. Normalize customer identifiers, deduplicate rows, import a sample, and confirm that the related records appear under the intended contact or company. Compare a count of imported records with the source and sample key fields, including empty values and unusual date formats. Keep rollback and source exports available according to the data-governance plan until the imported model has been accepted.<\/p>\n Custom tables can improve filtering and list-view analysis when records are structured consistently. Act! Premium v26 introduced improvements for certain Premium for Web Custom Tables workflows, including multi-select filtering, list-view selection, and summary controls. Those are product- and version-specific features, not evidence that every edition supports an identical query designer or that users automatically have a live cross-system dashboard.<\/p>\n A useful pilot report might list all active contracts by renewal month and owner, with records lacking a renewal date flagged rather than silently excluded. A separate view could show upcoming equipment warranty expirations for a particular account. If the report is used to make a decision, employees should be able to trace an aggregate number back to the underlying records and understand which statuses were included.<\/p>\n Integrations with finance, marketing, help-desk or project systems require explicit interfaces and field mappings. Do not assume every Custom Tables event automatically triggers a supported external action. Where a current Act! edition exposes an approved API or integration mechanism, define the direction of synchronization, retry behavior, duplicate-handling rules, and the system of record. Small integration failures should be logged and repairable without replaying every customer interaction.<\/p>\n The Act! Premium v26 changes<\/a> provide historical context for Custom Tables improvements, while the Act! Sidebar for Outlook<\/a> addresses a different problem: accessing contact and history context inside an email workflow. Those features can complement each other, but they do not replace the need for correct ownership and permissions on the underlying CRM records.<\/p>\n Act! markets Custom Tables for supported customer editions and may price the capability as an additional subscription depending on the package. The set of supported functions can differ between desktop, web and cloud configurations, and specific features may depend on version or an active subscription. Confirm those constraints directly in the organization’s product and entitlement documentation before promising a workflow to users or budgeting its benefits.<\/p>\n An administrator should verify whether the planned table is supported on the edition in use, whether the intended users can open and modify it, how backups handle the records, and what happens during an upgrade. For organizations with legacy Act! databases, the migration path and field limits may also matter. Build a proof of concept in a non-production environment and test it with users whose roles and permissions match the expected production group.<\/p>\n A deployment checklist should be based on acceptance tests, not feature descriptions. Can an authorized user create a contract? Can another user find it from the correct contact? Do restrictions prevent an unprivileged person from changing an owner-only field? Does a report identify records with missing dates? Can an error during import be corrected without damaging contact history? These are observable outcomes against which the design can be accepted.<\/p>\n Begin with one clearly bounded record type and a small set of users. Train staff to identify the authoritative record and enter information consistently, then review duplicate rates, missing fields, time spent searching and correction effort. Expand the model only after employees use the initial data reliably. Adding dozens of tables at once can recreate the complexity of the spreadsheets the organization hoped to retire.<\/p>\n The strategic value of Custom Tables is that useful operational records can stay connected to the people, companies and activities they describe. That value is strongest when the data model reflects real workflows, permissions are tested, updates have a clear owner, and reports are transparent about their limits. A custom table can support better decisions; it cannot by itself guarantee accurate data, compliant processes or successful automation.<\/p>\n","protected":false},"excerpt":{"rendered":" A customer relationship management system can hold far more useful information than names, email addresses and sales opportunities. An insurance broker may need to understand several policies associated with one client. A service company may need to track equipment, warranties and renewal dates separately from the contact who requested the work. A project consultancy may […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1094],"tags":[],"class_list":["post-4863","post","type-post","status-publish","format-standard","hentry","category-others"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tactive<\/code>, pending renewal<\/code> or closed<\/code> should have an agreed definition and an accountable owner.<\/p>\nUse reporting and integration capabilities realistically<\/h3>\n
Check licensing, edition and deployment constraints<\/h3>\n
Grow the data model only when the operational need is proven<\/h3>\n