Dedicated CRM
Not a CRM - fails on pipeline stages; status, resolution, actual close date, opportunity reporting unresolved
Core objects
In full
COMPANIES, CONTACTS, OPPORTUNITIES and ACTIONS are four separate entity tables in the shipped database, each with its own key range, and companies and contacts are described as separate atomic items with the relation table CONT_COMP holding the link rather than a company field on the contact. Opportunities associate through OPPO_COMP and OPPO_CONT, and an action - the object covering both scheduled appointments and unscheduled tasks - associates through ACTI_OPPO, ACTI_COMP and ACTI_CONT. The vendor describes these many-to-many links as a major strength of the product and lists opportunities among the item types an agenda appointment can be attached to.
Source: https://help.efficy.io/manuals/dev/en/dbst_relationtables.html, https://help.efficy.io/manuals/dev/en/dbst_entitytables.html, https://help.efficy.io/manuals/dev/en/dbst_tableoverview.html, https://help.efficy.io/manuals/user/en/e121_linkeditems.html, https://help.efficy.io/manuals/user/en/e121_agenda.html
Verification: Verified
Pipeline stages
In part
An opportunity holds a status drawn from the shipped look-up table LK_OPPO_STATUS, and the Kanban view lays those statuses out as columns grouped into silos such as Pre-sales, Proposal and Outcome, with the user dragging an opportunity from one status to the next. Each status carries a success rate, so the column headers can show a weighted amount alongside the count and the total, and the vendor warns that the values in LK_OPPO_STATUS feed the queries behind its standard sales reports, including sales funnel analysis and turnover forecasts. Ruled 30 Aug 2026: the order is visible only in the board view and no vendor page states it is stored, so it is not established as held on the data.
Source: https://help.efficy.io/manuals/user/en/e121_kanban.html, https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html
Verification: Verified
Status
No verdict
No enumeration of the attributes Efficy ships on the opportunity record could be reached. The vendor's own database structure manual declines to list the columns of its entity tables and instructs the reader to open the matching window in the user interface and compare it with the table, and the opportunities section of that manual carries a screenshot rather than a field list. What is documented points toward the open-or-closed fact being a property of the status value rather than an attribute of its own: the database setting oppoOrderStatusId names the status that marks an opportunity converted to an order, and the Boolean field OPENED, described as a standard field every item type carries, is documented as not used by Efficy in the standard implementation. Neither of those enumerates what the opportunity object holds, so the claim that no open-or-closed attribute ships cannot be made on this evidence.
Source: https://help.efficy.io/manuals/dev/en/dbst_entitytables.html, https://help.efficy.io/manuals/dev/en/dbst_projectentities.html, https://help.efficy.io/manuals/dev/en/dbst_variousvalues.html, https://help.efficy.io/manuals/admin/en/dsgn_definedatabasesettings.html
Searched: Read the Efficy database structure manual end to end where it was reachable - the table overview sorted by key, table and field naming conventions, entity tables, project entities where OPPORTUNITIES is documented, relation tables, look-up tables, database values, values in actions and the other system tables - plus the opportunities, Kanban, create items and modules chapters of the efficy 2024 user manual and the database settings reference. The Efficy Developer Network pages at help.efficy.io/edn and the whitepaper tree at help.efficy.io/HelpEfficy render as an application shell with no server-side content, help.efficy.com redirects every deep link to the help center home, and no public API object reference for the opportunity was found.
Verification: Pending vendor verification
Resolution
No verdict
The same gap. Won appears in the documentation as a status value rather than as an attribute: the setting oppoOrderStatusId identifies which status means the opportunity became an order, and lost is evidenced by the shipped look-up LK_OPPO_LOSTREAS holding reasons for lost opportunities. That is consistent with the outcome being read from the status the opportunity sits on, but no source reviewed enumerates the opportunity object's attributes, so it cannot be established that no separate won or lost marker ships.
Source: https://help.efficy.io/manuals/admin/en/dsgn_definedatabasesettings.html, https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html, https://help.efficy.io/manuals/dev/en/dbst_entitytables.html
Searched: As for status: no reachable Efficy page enumerates the shipped fields of the OPPORTUNITIES table, the developer network and whitepaper trees serve an application shell only, and the database structure manual documents the opportunity with a screenshot and directs the reader to the user interface.
Verification: Pending vendor verification
Value
In full
The vendor's instruction for adding a sales opportunity is to enter the amount, expected success rate, account manager and conclusion date, so the amount is a shipped field rather than one the buyer creates. Efficy treats that figure as money: the Kanban column headers show the number of opportunities, the amount and a weighted amount that takes the success rate into account, and the opportunity statuses feed standard turnover forecast reports.
Source: https://help.efficy.io/manuals/user/en/e121_createitems.html, https://help.efficy.io/manuals/user/en/e121_kanban.html, https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html
Verification: Verified
Scope of work
In full
Products are a shipped entity in their own right and attach to opportunities through the relation table PROD_OPPO, which also carries a Sheet field holding a document with the technical description of what is being supplied. The vendor's opportunity management page describes quotes being generated from the opportunity, and Products is a listed module of the product.
Source: https://help.efficy.io/manuals/dev/en/dbst_relationtables.html, https://help.efficy.io/manuals/user/en/e121_modules.html, https://www.efficy.com/features/opportunities-management/
Verification: Verified
Expected close date
In full
A date for when the opportunity is expected to be settled ships on the record. The vendor's instruction for adding a sales opportunity names a conclusion date among the fields the user fills in, and the Kanban post-it for an opportunity displays the Efficy user, the reference and name, the amount, the chance of success and the target date, so open opportunities carry a forward-looking date the buyer did not have to create.
Source: https://help.efficy.io/manuals/user/en/e121_createitems.html, https://help.efficy.io/manuals/user/en/e121_kanban.html
Verification: Verified
Actual close date
No verdict
A forward-looking conclusion date is entered when the opportunity is created, and no page reviewed describes a second field holding the date an opportunity actually ended or states that Efficy stamps a date when the status changes to the order status. The Kanban instruction for closing an opportunity covers only the drag from one status column to another, and says the move modifies the amounts and the success rate, with no mention of a date. This cannot be settled either way, because the documentation that would enumerate the opportunity's shipped fields does not exist in published form.
Source: https://help.efficy.io/manuals/user/en/e121_createitems.html, https://help.efficy.io/manuals/user/en/e121_kanban.html, https://help.efficy.io/manuals/dev/en/dbst_entitytables.html
Searched: Searched the efficy 2024 user manual chapters for opportunities, Kanban, creating items, editing items, list views and search options, the database structure manual's project entities, database values and naming convention pages, and the database settings reference, for a closing date, date of order or won date on the opportunity. Nothing describes a date recorded at close, and nothing enumerates the fields the record carries.
Verification: Pending vendor verification
Opportunity owner
In full
The vendor's instruction for adding a sales opportunity names the account manager among the fields entered, and the Kanban post-it shows the Efficy user the opportunity belongs to. The link is a shipped structure rather than a custom field: OPPO_USER is a standard relation table between opportunities and users, and LK_OPPO_USERROLE holds the roles a user can take on an opportunity.
Source: https://help.efficy.io/manuals/user/en/e121_createitems.html, https://help.efficy.io/manuals/user/en/e121_kanban.html, https://help.efficy.io/manuals/dev/en/dbst_relationtables.html, https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html
Verification: Verified
Linked buyer
In full
OPPO_CONT is a shipped relation table linking opportunities to contacts, held separately from OPPO_COMP which links them to companies. Efficy also ships look-ups describing the person's part in the sale - LK_OPPO_CONTROLE for the contact's role, LK_OPPO_CONT_RSP for responsibility and LK_OPPO_CONT_DCS for decision-making - so the link to the individual is a first-class part of the model.
Source: https://help.efficy.io/manuals/dev/en/dbst_relationtables.html, https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html
Verification: Verified
Record preservation
In full
Closing an opportunity moves it to another status rather than removing it: the Kanban view shows an opportunity being dragged into the Order column, and the vendor warns that the values in LK_OPPO_STATUS drive the queries behind its standard sales reports for actual sales, sales funnel analysis and turnover forecasts, which require settled opportunities to remain queryable. The item timeline keeps the record's own history of field changes and links for sales opportunities among other item types.
Source: https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html, https://help.efficy.io/manuals/user/en/e121_kanban.html, https://help.efficy.io/manuals/user/en/e121_timeline.html
Verification: Verified
Structured lost reasons
In full
LK_OPPO_LOSTREAS is a shipped look-up table holding the reasons an opportunity was lost, so the reason is a coded value rather than free text, and LK_OPPO_COMPET separately holds the competitor. Look-up values are reportable: queries are built by selecting a table and its fields and defining criteria on them, a KPI widget displays a number generated by a query with the number of sales opportunities with a specific status given as the vendor's own example, and a color can be added to a look-up table so its values chart properly.
Source: https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html, https://help.efficy.io/manuals/user/en/e121_howcreatequeries.html, https://help.efficy.io/manuals/user/en/cfsa_kpiwidgets.html
Verification: Verified
Email sync
In part
Efficy holds mail as an entity of its own and sends from inside the product through Instant E-mail commands and templates, with mail linked to companies, contacts, opportunities and documents. Inbound, the Auto Mail Uploader service connects to the users' mailboxes - IMAP, Microsoft Exchange, Gmail and Yahoo Mail are named - and retrieves the contents of monitored subfolders at intervals, so mail reaches Efficy through a server-side mailbox connection rather than an add-in. That connection carries mail one way. Getting a message into it depends on the user filing it into an Efficy subfolder or copying a dedicated address, both of which are hand work rather than a sync, and the Exchange and Google server-side synchronizations documented by the vendor cover contacts, companies, tasks and agenda items, with the Google page stating explicitly that e-mail messages are not synchronized.
Source: https://help.efficy.io/manuals/admin/en/scpr_automailuploader.html, https://help.efficy.io/manuals/user/en/e121_emails.html, https://help.efficy.io/manuals/admin/en/scpr_exchangesync.html, https://help.efficy.io/manuals/admin/en/scpr_googlesync.html
Verification: Verified
Calendar sync
In full
Two server-side synchronizations run on the activity object itself. The Microsoft Exchange synchronization covers contacts, companies, tasks and agenda items and runs in both directions, with the vendor stating that changes made on the user's device are uploaded to Efficy automatically to give a real-time agenda. The Google synchronization covers appointments and tasks, and the vendor documents behavior in the Google to Efficy direction as well, noting that attendees on a Google Calendar meeting synced into Efficy are linked as contacts and that recurring appointments created in Google are the exception that does not come across. Coverage is Exchange and Google only, and the separate iCalendar agenda-sharing feature is explicitly described by the vendor as read-only publication and not a synchronization.
Source: https://help.efficy.io/manuals/admin/en/scpr_exchangesync.html, https://help.efficy.io/manuals/admin/en/scpr_googlesync.html, https://help.efficy.io/manuals/admin/en/scpr_googlesyncoperation.html, https://help.efficy.io/manuals/user/en/intg_agendasharing.html
Verification: Verified
Schedulable activity types
In full
Actions are a single shipped entity covering both scheduled appointments and unscheduled tasks, distinguished by the field ISPLANNED whose documented values are task, appointment and recurring appointment. The kind of work is carried by look-up tables the account controls - LK_ACTI_NATURE for the nature of the activity, alongside LK_ACTI_MODE, LK_ACTI_LOCATION and LK_ACTI_PRIORITY - and look-up tables are maintained by the administrator through the Designer. Activities are reportable by type: list views can be filtered and grouped, and queries select any table and fields and define criteria on them.
Source: https://help.efficy.io/manuals/dev/en/dbst_valuesactions.html, https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html, https://help.efficy.io/manuals/user/en/e121_worklists.html, https://help.efficy.io/manuals/user/en/e121_howcreatequeries.html
Verification: Verified
Opportunity reporting
No verdict
No verdict. A revenue forecast is native and documented: the vendor states that the opportunity statuses feed the queries behind standard sales reports for actual sales, sales funnel analysis and turnover forecasts, and the Kanban column headers show a weighted amount that applies each status's success rate in real time. The other two could not be settled. Sales funnel analysis is described only by name, and a funnel of counts by stage is a distribution rather than a rate, so it cannot be read as stage-to-stage conversion. No supplied win and loss rate report or indicator is documented, and although queries, indicators, KPI widgets and amCharts dashboards let a buyer build measures, the query wizard is documented as selecting tables and fields and defining criteria, with no statement that it can express a proportion. The vendor does not publish a catalog of its standard reports, so the absence of a conversion or win-rate report cannot be established either. Qlik Sense and SAP Crystal Reports sit alongside the product and are not counted here.
Source: https://help.efficy.io/manuals/dev/en/dbst_lookuptables.html, https://help.efficy.io/manuals/user/en/e121_kanban.html, https://help.efficy.io/manuals/user/en/e121_reports.html, https://help.efficy.io/manuals/admin/en/rpts_introduction.html, https://help.efficy.io/manuals/user/en/cfsa_kpiwidgets.html, https://help.efficy.io/manuals/user/en/e121_howcreatequeries.html
Searched: Searched the efficy 2024 user manual chapters for reports, dashboards and widgets, queries and creating queries, the client configuration manual's widget chapters including chart, grid and KPI widgets, and the administrator manual's reporting solution chapter, for a funnel conversion rate, a win rate and a forecast report. Only the forecast is evidenced, and no page lists which reports ship as standard.
Verification: Pending vendor verification