Performing intelligent affinity-based field updates

Abstract

This application describes a method, system, and non-transitory computer-readable medium for updating fields in records. Fields are initially displayed according to how frequently they are updated. One of the fields is selected, and then records of the record type containing the selected field are displayed. One of the records is selected, and a form is displayed that allows a user to update the value stored in the selected field of the selected record.

Description

[Background technology]

[0001] To conduct business and perform day-to-day operations, business customers need to keep track of multiple records. Often, as a customer's business or project grows, the number of records kept grows as well.

[0002] Every client needs to update their records in order to keep information up to date and plan ahead. Furthermore, every client or company typically has its own way of planning and storing information, updating records internally, etc., that is acceptable to management and stakeholders. However, due to the size of the records and the often unique ways and formats in which information is stored, updating records cannot be streamlined and often occurs in a rather cumbersome manner.

[0003] For example, such customers may be required to select the record they want to update from within a list of records. Having to do so from hundreds or even thousands of records when only one update is desired often results in significant time inefficiency and impedes the customer's performance efficiency. Furthermore, reaching some records often requires other records to be filled in first (pre-requisite records) or other steps to be taken, and these pre-requisite records or steps may take the same values ​​or actions each time, creating further obstacles in time and performance efficiency. Thus, when monitoring and planning projects, opportunities, or daily operations, such customers would benefit from an easier way to update records that avoids the hassle associated with selecting a record through a long list of records each time or pre-filling values ​​each time. [Brief explanation of the drawings]

[0004] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the present disclosure and, together with the description, serve to further explain the principles of the embodiments and enable those skilled in the art to make and use the embodiments individually or in combination. [Figure 1] FIG. 1 is a block diagram of an example embodiment in which a user of a customer user can use a user module to update corresponding records in a multi-tenant data repository via a central module. [Figure 2] 1 illustrates a modular interface structure for a customer's users, records residing in a multi-tenant data repository, and update interface structure, according to some embodiments. [Figure 3] 1 illustrates an example screen of a graphical user interface (GUI) for selecting fields according to one or more embodiments. [Figure 4] 1 illustrates an example screen of a GUI for selecting a record according to one or more embodiments. [Figure 5] 1 illustrates an exemplary form for updating values ​​in selected fields of selected records in accordance with one or more embodiments. [Figure 6] 1 shows a flowchart for updating fields in a record in accordance with one or more embodiments. [Figure 7] 1 shows an exemplary screen for selecting a list of records according to one or more embodiments. [Figure 8] 1 illustrates an exemplary form for updating values ​​in selected fields of a record in accordance with one or more embodiments. [Figure 9A] 1 illustrates a neural network according to one embodiment. [Figure 9B] 1 illustrates a random forest classifier that uses a forest of classification trees, according to one embodiment. [Figure 10A] 1 shows a graph illustrating a weighted SVM, according to one embodiment. [Figure 10B]10 shows a graph illustrating feature weighted SVM importance according to one embodiment. [Figure 11] FIG. 1 is a block diagram of an exemplary cloud computing environment, according to one embodiment. [Figure 12] FIG. 1 is a block diagram of example components of the underlying architecture of any of the systems presented in the following embodiments.

[0005] The drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference number. In the drawings, like reference numbers may indicate identical or functionally similar elements. DETAILED DESCRIPTION OF THE INVENTION

[0006] Provided herein are embodiments of systems, apparatus, devices, methods, and / or computer program products, and / or combinations and subcombinations thereof, for predicting records that a user is likely to edit and displaying the resulting records in an efficient manner, allowing the user to edit the values ​​of the records without having to waste a large amount of time or perform a large amount of steps.

[0007] 1 is a block diagram of a data transfer environment 100 illustrating the interaction between a user module 102, a central module 104, and a multi-tenant data repository 106 that may be accessed by a user of a customer (e.g., a business customer in a cloud-based records management system) seeking to update the customer's records in the multi-tenant data repository. The multi-tenant data repository 106 is accessed by multiple tenants (customers), each with their own data and records stored in the multi-tenant data repository 106.

[0008] According to one embodiment, the central module 104 and the user module 102 may comprise one or more separate computer systems, such as computer system 1200 shown in FIG. 12 , which may include a personal computer, a mobile device, or the like. To help explain the methods described herein, one exemplary embodiment of an underlying structure will be described. The underlying structure of computer system 1200 shown in FIG. 12 may implement database and data transmission / reception. While such a computer system may include the user module 102, the central module 104, and the multi-tenant data repository 106 according to the embodiment described above, in the embodiment described below, the user module 102 and the central module 104 reside on different computer systems 1200. The computer system 1200 may include one or more processors (also referred to as central processing units or CPUs), such as processor 1204. The processor 1204 may be connected to a communication infrastructure or bus 1206.

[0009] The computer system 1200 may be virtualized or may include user input / output devices 1203 such as a monitor, keyboard, pointing device, etc., which may communicate with a communications infrastructure 1206 through a user input / output interface 1202.

[0010] One or more processors 1204 may be graphics processing units (GPUs). In one embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process record data received from tables in the multi-tenant data repository 106 from relevant values ​​of fields of the records when data is to be processed in bulk, for example, to perform a scoring assessment for a particular customer of a particular user or for all users of a particular group of a particular customer, to take into account record relevance factors when scoring which records are likely to be accessed (as described below), or to detect patterns in fields of previously filled records. GPUs may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common in computer graphics applications, images, videos, word processing documents, PDF files, and the like, any of which may include table data received from the multi-tenant data repository 106 described above.

[0011] Computer system 1200 may also include a main or primary memory 1208, such as random access memory (RAM). Main memory 1208 may include one or more levels of cache, including a second-level cache.

[0012] The computer system 1200 may also include one or more secondary storage devices or memories 1210. The secondary memory 1210 may include, for example, a hard disk drive 1212 and / or a removable storage device or drive 1214, which may interact with a RAID array, or removable storage unit 1218, which may combine multiple physical hard disk drive components (e.g., SSDs or SATA-based disk drives) into one or more logical units. The removable storage unit 1218 may include any computer-usable or readable storage device that stores computer software (control logic) and / or data, including a remotely accessed network drive. The removable storage unit 1218 may be a program cartridge and cartridge interface, a removable storage memory chip (e.g., an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and / or any other removable storage unit and associated interface. The removable storage drive 1214 may read from and / or write to the removable storage unit 1218.

[0013] Secondary memory 1210 may include other means, devices, components, implements, or other approaches for making computer programs and / or other instructions and / or data accessible by computer system 1200. Such means, devices, components, implements, or other approaches may include, for example, removable storage unit 1222 and interface 1220. Examples of removable storage unit 1222 and interface 1220 may include a program cartridge and cartridge interface (such as those found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and / or any other removable storage unit and associated interface.

[0014] Computer system 1200 may further include a communications or network interface 1224. Communications interface 1224 may enable computer system 1200 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referred to by reference numeral 1228). For example, communications interface 1224 may enable computer system 1200 to communicate with external or remote entities 1228 over communications path 1226, which may be wired and / or wireless (or a combination thereof) and may include any combination of a LAN, a WAN, the Internet, etc. Control logic and / or data may be transmitted to and from computer system 1200 via communications path 1226.

[0015] Computer system 1200 may be any one or any combination of a personal digital assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, a tablet, a smartphone, a smartwatch or other wearable, an appliance, part of the Internet-of-Things, and / or an embedded system, to name a few non-limiting examples.

[0016] Any applicable data structures, file formats, and schemas in computer system 1200 may be derived from standards, including but not limited to JavaScript® Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations, alone or in combination, and may be used to transmit or receive data (e.g., between any of source module 102, central module 104, and multi-tenant data repository 106 of FIG. 1 ). Alternatively, proprietary data structures, formats, or schemas may be used exclusively or in combination with known or open standards.

[0017] In some embodiments, a tangible, non-transitory apparatus or article of manufacture that includes a tangible, non-transitory computer-usable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 1200, main memory 1208, secondary memory 1210, and removable storage units 1218 and 1222, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (e.g., computer system 1200), can cause such data processing devices to operate as described herein.

[0018] The computer system 1200 may be configured to support a variety of cloud computing solutions, including, but not limited to, remote or distributed cloud computing solutions, such as the cloud computing environment 502 described below; local or on-premise software ("on-premise" cloud-based solutions); "as a service" models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (FaaS), and the like). and / or a client or server accessing or hosting any application and / or data through any delivery paradigm, including hybrid models including any combination of the foregoing examples or other service or delivery paradigms. For example, the method of claim 6 (described below) and the GUIs of Figures 3-5 and 7-8 may be provided as part of a SaaS execution from a distributed cloud computing environment executed from a central module 104 including a multi-tenant data repository 106.

[0019] As one exemplary approach in implementing the multi-tenant data repository 106, the computer system 1200 can use an in-memory database with persistence that stores and accesses data objects from the primary memory 1208 of the computer system 1200, with a transaction log for persistence stored in secondary memory 1210. Such a database can be used to store and access the configuration data objects of these repositories, where record-accessed data based on monitoring user sessions is parsed into the multi-tenant data repository 106.

[0020] Alternatively, to store and access the configuration data objects of these repositories, computer system 1200 may use less primary memory 1208 than the first embodiment described above, implementing only a portion of the data present as an in-memory database to reduce the in-memory footprint, and instead store most of the data as a disk-based database in secondary memory 1210 (more frequently accessed data stored in primary memory 1208 and less frequently accessed data stored in secondary memory 1210).

[0021] If the multi-tenant data repository 106 is implemented as a separate system 1200, it can transmit data to a linked network entity through a communication or network interface 1224, e.g., through an internal network, the Internet, etc., and the user module 102 and the central module 104 can include entities 1228 that reside on internal or external networks that can be accessed through a communication path 1226. Alternatively, if the central module 104 resides jointly with the multi-tenant data repository 106 within the computer system 1200, the computer system 1200 can implement a database using the communication infrastructure 1206 for communication between the central module 104 and the multi-tenant data repository 106, but can transmit data to the user module 102 through the communication interface 1224 through the communication path 1226, in which the central module 104 is a network entity 628.

[0022] 11 , in a block diagram of an exemplary environment 1100 in which the systems and / or methods described herein may be implemented, a cloud computing environment 1102 may include a backend platform 1108. The central module 104 of FIG. 1 described above may also include a host such as the cloud computing environment 1102. The cloud computing environment 1102 may be accessed by a central module computing system 1104 of the same type of computing system 1200 described above, which in one embodiment is included in the central module 104. In this case, the central module computing system 1104 of FIG. 12 may access the cloud computing environment 1102 by a communication or network interface 1224 as shown in FIG. 12, and the network gateway 1106 may include a remote entity 1228 accessed by a communication path 1226 of the central module computing system (in this regard, the three entities 1102, 1104, and 1106 shown in FIG. 11 would correspond to the central module 104 of FIG. 1). Alternatively, the computing cloud environment 1102 itself may correspond to the remote entity 1228 in FIG. 12 and may be accessed directly by the central module computing system 1104 over a communication path 1226, for example through an application protocol interface (API), eliminating the need for a network gateway 1106 (both options are shown in FIG. 11 , with the flow path above the central module computing system 1104 using the network gateway 1106 and the flow path below the central module computing system 1104 connecting directly to the cloud computing environment 1102, both shown using dashed bidirectional lines).

[0023] The devices of environments 1100 and 100 may be connected through wired connections, wireless connections, or a combination of wired and wireless connections.

[0024] In one exemplary embodiment, one or more portions of the data transfer environment 100 may be an ad-hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless wide area network (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the public switched telephone network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, any other type of network, or a combination of two or more such networks.

[0025] As explained above, the central module 104 of Figure 1 may have the central module computing system 1104 shown in Figure 11, which includes the same type of computer system as the computer system 1200 shown in Figure 12. The user modules 102 or the multi-tenant data repository 106 may access the central module 104 through the central module computing system 1104, which in one embodiment may be an external network entity 1228 from the perspective of the central module computing system 1104, and may exchange data in the form of data packets through a communication path 1226 of the communication interface 1224 of the computing system 1104, for example, using TCP / UDP / FTP / HTML5 protocols. Alternatively, in one embodiment, the source module 102 can access the central module 104 through a front-end application 1110a (e.g., a web browser application, a web browser extension, a proprietary OS application, a standalone executable application, a command line access shell program, FTP / UDP / TCP / HTML5 protocols, etc.) hosted as an application 1110a on a computing resource 1110 (described below) in the cloud computing environment 1102 hosted by the central module 104.

[0026] 11 may include a server or a group of servers. In one embodiment, the backend platform 1104 may host a cloud computing environment 1102. It may be understood that the backend platform 1102 may not be cloud-based or may be partially cloud-based.

[0027] The cloud computing environment 1102 may include an environment that delivers computing as a service (the aforementioned "CaaS"), thereby providing shared resources, services, and the like to the central module computing system 1104 and / or the backend platform 1108. The cloud computing environment 1102 may provide computation, software, data access, storage, and / or other services without requiring end-user knowledge of the physical location and configuration of the systems and / or devices delivering the services. For example, the central module computing system 1104, as well as the source modules 102, may receive data stored in or hosted on a database in the computing resources 1110 in the backend platform 1108 through an application protocol interface (API) or any of the various communication protocols previously listed. The cloud computing environment 1102 may include the computing resources 1110.

[0028] Each computing resource 1110 includes one or more personal computers, workstations, computers, server devices, or other types of computing and / or communication devices, such as the types of computer system 1200 described above. A computing resource 1110 may host a backend platform 1108. A cloud computing resource may include compute instances running on a cloud computing resource 1110. A cloud computing resource 1110 may communicate with other cloud computing resources 1110 via wired connections, wireless connections, or a combination of wired and wireless connections, as described above.

[0029] Computing resources 1110 may include a group of cloud resources, such as one or more applications (“APPs”) 1110a, one or more virtual machines (“VMs”) 1110b, virtualized storage (“VS”) 1110c, and one or more hypervisors (“HYPs”) 1110d.

[0030] An application 1110a may include one or more software applications that may be provided to or accessed by computer system 1200. In one embodiment, central module 104 may include only cloud computing environment 1102 running locally on computer system 1200 of central module computing system 1104. Application 1110a may include software associated with backend platform 1108 and / or any other software configured to be provided across cloud computing environment 1102 (e.g., to source module 102). Application 1110a may send / receive information from one or more other applications 1110a via one or more virtual machines 1110b. In this manner, computing resources 1110 may be able to access each other's applications 1110a through virtual machines 1110b. In an alternative embodiment, a separate central module computing system 1104 is not required, and the central module 104 includes only a cloud computing environment 1102, which is hosted and executed by the computing resources 1110 and communicates with the source module 102 using a communication interface 1224 of one of the computing resources 1110 or via app 1110a, using any of the various communication protocols described above.

[0031] The virtual machine 1110b may include a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. This may be particularly useful in alternative embodiments where there is no separate central module computing system 1104 of the type of computer system 1200. In this embodiment, the central module computing system 1104 may be a virtualized machine 1110b and may communicate with the source module 102 via the application 1110a using the various communication protocols listed above. The virtual machine 1110b may be either a system virtual machine or a process virtual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system (OS). A process virtual machine may execute a single program and support a single process. The virtual machine 1110b may run on behalf of a user (e.g., an administrator of the central module 104) and / or on behalf of one or more other backend platforms 1108, and may manage the infrastructure of the cloud computing environment 1102, such as data management, synchronization, and access to records and their values ​​from the multi-tenant data repository 106.

[0032] Virtualized storage 1110c may include one or more storage systems and / or one or more devices that use virtualization techniques within the storage systems or devices of the computing resource 1110. With respect to storage systems, types of virtualization may include block virtualization and file virtualization. Block virtualization may refer to the abstraction (or separation) of logical storage from physical storage, allowing access to the storage system regardless of the physical storage or heterogeneity. This separation may allow administrators of the central module 104 flexibility in how to manage notifications specified for different end users in the user module 102, as well as storage of evaluation data (described below) from records of data accessed from the multi-tenant data repository 106. File virtualization may eliminate dependencies between data accessed at the file level and where the file is physically stored. Such block and file virtualization may enable optimization of storage usage, server consolidation, and / or performing non-disruptive file migrations.

[0033] Hypervisor 1110d can provide a hardware virtualization approach that allows multiple operating systems (e.g., “guest operating systems”) to run simultaneously on a host computer, such as computing resource 1110, which may include a computing system of the type computing system 1200, and in this manner can host the virtualized hardware of central module computing system 1104. Hypervisor 1110d can present a virtual operating platform to the guest operating systems and can manage multiple instances of various operating systems as these “guest operating systems,” which can share virtualized hardware resources, such as RAM, that can access data in the form of a database of records, for example, in multi-tenant data repository 106. Alternatively, secondary memory may be accessed using virtualized storage 1110c or on physical storage, such as hard disk drive 1112, of computing resource 1110 of a computing system of the type computing system 1200. The embodiments described thus far also contemplate using a combination of RAM and secondary memory to access a database, where part of the database may be in-memory and part of the database may be stored in a file.

[0034] Additionally, user module 102 may also include environment 1100 with cloud computing environment 1102 instead of only computing systems of the type of computing system 1200. This environment is described with reference to FIG. 2, where user module 202 may be part of a larger group 204 that includes multiple user modules 202. Similarly, customer 208 may include several groups 204. This reflects the real-world situation where customers that are tenants of multi-tenant database 106 may be businesses.

[0035] In one or more embodiments, the multitenant data repository 206 stores multiple records of different record types. A record type is sometimes referred to as a record schema. As shown in FIG. 2, the multitenant data repository 206 stores record A1 290, record A2 291, record B1 292, record B2 293, and record B3 294. Record A1 290 and record A2 291 are both records of record type A and therefore have the same fields (e.g., field 1, field 2, field 3). In contrast, record B1 292, record B2 293, and record B3 294 are all records of record type B and therefore have the same fields (e.g., field W, field X, field Y, field Z). A record type can include any number of fields. Two records may belong to the same record type and therefore have the same fields, but the two records may store different values ​​for a particular field. For example, field 1 may be a city field. Record A1 290 might store "Miami" in field 1, and record A2 291 might store "Chicago" in field 1. Those skilled in the art having the benefit of this disclosure will understand that some fields are updated frequently (e.g., daily, weekly, etc.), while other fields are updated infrequently or not at all.

[0036] In one or more embodiments, a customer 208 (e.g., a company) may have several project teams or groups 204, which may include specialists such as sales staff, engineers, troubleshooters, accountants, etc. These specialists or users 202 in various roles will access the multitenant database repository 206 through an interface 210. The interface 210 may be accessed by users to view records in the multitenant database repository 206, create records, delete records, and update records (e.g., modify / edit one or more fields of a record). The interface 210 may be implemented as a graphical user interface (GUI) having one or more screens and / or forms. Each screen may have GUI components (e.g., text boxes, drop-down boxes, radio buttons, buttons, etc.) that can be manipulated by a user. The interface 210 may be accessed from any type of user computing device, including a desktop personal computer (PC), a laptop, a smartphone, a tablet PC, etc.

[0037] 3 shows an example screen 300 of the interface 210 according to one or more embodiments. The screen 300 can be displayed on the user module 202 (e.g., a smartphone). The screen 300 can correspond to a user's home page. The screen 300 displays a list 314 of fields (e.g., a list of field identities / names) belonging to a record type in the multi-tenant data repository 206. In one or more embodiments, the first N entries in the list (e.g., N=5) correspond to the N most frequently updated (e.g., modified, edited) fields over a period of time by the user, by other users belonging to the same team or company as the user, by other users sharing the same demographic profile as the user, etc. The remaining entries on the list can include the remaining fields (e.g., fields not in the top N fields) sorted alphabetically or based on how recently the fields were updated. Additionally or alternatively, the entire list of fields may be sorted by how frequently the fields are accessed, and the top N fields are marked as "suggested." In one or more embodiments, only the top N fields are displayed (e.g., list 314 has only the top N most frequently updated fields). In one or more embodiments, each field is associated with a score, and the fields in list 315 are displayed according to score ordering (e.g., highest to lowest). Those skilled in the art with the benefit of this detailed description will understand that a record type may have any number of fields (e.g., 100+ fields) and that multiple record types may exist. Thus, generating list 314 may be computationally expensive if it includes every field. Furthermore, if list 314 is displayed on a smartphone or a computing device with a smaller screen size, it may be difficult for a user to navigate list 314 with a large number of fields.Limiting the list 314 to the top N most frequently updated fields conserves computational resources and reduces the navigation burden for the user.

[0038] Although not shown, each entry in the list may identify a record type that includes the field. For example, if the first entry in the list 314 identifies field W, the first entry in the list may also identify record type B because, as shown in FIG. 2, field W is a field of record type B. A drop-down box or another type of GUI component may be used instead of the list 314 to display frequently updated fields and enable field selection. Radio buttons or regular buttons may also be used to enable field selection. To help the user find a field, a search box 302 may be displayed, allowing the user 202 to type the name of the field and find it in order to update its value in a particular record. Data entered by the user as keystrokes in the box 302 or by mouse clicks on the field 314 may be recorded by the central module 104 to provide training data on which fields 314 the user selected, which is used as described below. At the same time, factors related to the user and business associated with field access (e.g., time of day, weather, whether the user 202 was traveling on business to the customer 208, day of the week, the existence of an ongoing business transaction for the customer 208, etc.) may also be recorded by the central module for each field 314 that the user accesses by clicking or searching in box 302 on screen 300 of FIG. 3.

[0039] FIG. 4 shows another example screen 400 according to one or more embodiments. Screen 400 and screen 300 can belong to the same GUI. Screen 400 can be displayed after a user selects a field from list 314 in screen 300. As shown in FIG. 4, screen 400 displays a field 405 selected by the user (from list 314) and a list 410 of records of the record type that include the selected field. For example, if a user selects field X from list 314, list 410 can include records B1, B2, and B3. All records in list 410 have the selected field (e.g., field X), but each record can have a different value for the selected field (e.g., field X). For example, if field X is a state, field X in record B1 might store "California," field X in record B2 might store "Texas," and field X in record B3 might store "Florida." List 410 of records can be sorted in any order. For example, list 410 may be sorted by how recently the records were accessed or modified. Screen 400 may have additional GUI components (not shown) that allow a user to search list of records 410 for a particular record and / or select one of the records in the list. Although screen 400 and screen 300 are shown as two separate screens, in one or more embodiments, screen 300 and screen 400 may be merged into a single screen. In such an embodiment, list 410 may only appear after a field is selected from list 314. A user can select one of the records from list 410. Selection can be performed by clicking one of the entries in list 410. Additionally or alternatively, selection can be performed by manipulating other GUI components, such as buttons and radio buttons.Although FIG. 4 shows a list 410, in other embodiments, the records may be displayed and selected using a drop-down box or another GUI component.

[0040] FIG. 5 illustrates an exemplary form 500 according to one or more embodiments. Form 500 may be part of the same GUI as screen 300 and screen 400. Form 500 may be displayed in response to a user selecting a record from list 410 (discussed above with reference to FIG. 4). Form 500 may display a selected record 506 and a selected field 508 (from list 314). Form 500 may also include a GUI component 516 (e.g., a text box) for collecting an updated value from the user for the selected field 508 in the selected record 506. When form 500 is initially displayed, GUI component 516 may be populated with the current value in the selected field of the selected record. The user can enter an updated value by manipulating GUI component 516. If the user selects a "Save" button 510, the updated value provided by the user is saved in the selected field of the selected record. If the user selects a "Cancel" button 512, the selected record is not updated. In one or more embodiments, GUI component 516 may be pre-filled by the system with expected update values ​​(discussed below). If the expected update values ​​are correct, the user can select "Save" button 510. Otherwise, the user can select button 518 to indicate that the expected update values ​​are incorrect.

[0041] FIG. 6 illustrates a flowchart for updating a record, according to one or more embodiments. The steps of FIG. 6 may be performed by one or more of the components discussed above with reference to FIGS. 1 and 2. In one or more embodiments, one or more of the steps shown in FIG. 6 may be omitted, repeated, and / or performed in a different order than that shown in FIG. 6. Thus, the scope of the present invention should not be considered limited to the particular arrangement of steps shown in FIG. 6. The steps shown in FIG. 6 may be implemented as computer-readable instructions stored on a computer-readable medium that, when executed, cause a processor to perform the process of FIG. 6.

[0042] At 602, scores for multiple fields are determined. As discussed above, a repository can store records of various record types. Each record type can include any number of fields. Some fields may be updated (e.g., modified, edited) quite frequently. Other fields may be updated infrequently or not at all. In one or more embodiments, the score for a field reflects how frequently the field is updated by the user, by other users on the same project team as the user, by other users belonging to the same company as the user, and / or by other users with the same demographic profile as the user. The score can be determined using machine learning. Additionally or alternatively, the score may be obtained from any source, including external sources. In one or more embodiments, each time a field of a record type is updated (regardless of the particular record), the score for that field is incremented by a constant k (e.g., k=1). The score then decays over time. Thus, a higher score indicates that the field is updated more frequently.

[0043] At 604, a subset of the fields is displayed (e.g., the identities / names of the fields are displayed). An example of the displayed fields is shown in FIG. 3 (discussed above). In one or more embodiments, only the fields with the top N scores are displayed. Those skilled in the art with the benefit of this detailed description will understand that a record type may have any number of fields (e.g., 100+ fields) and that multiple record types may exist. Thus, displaying every field may be computationally expensive. Furthermore, if all fields are displayed on a computing device with a smaller screen size (e.g., a smartphone), it may be difficult for a user to navigate through a large number of fields. Displaying only the fields with the top N scores conserves computational resources and reduces the navigation burden on the user. Furthermore, these displayed fields are most likely to include fields the user wants to update.

[0044] At 606, a field selection is received from the user. The user can select a field by clicking on it. Additionally or alternatively, each field may be displayed as a radio button and the user selects the field by selecting the radio button. Additionally or alternatively, fields may be displayed in and selected via a drop-down box.

[0045] At 608, records of the record type that include the selected field are displayed. The records may be displayed on the same screen as the field (in step 604) or on a different screen. An example of displayed records is shown in FIG. 4 (discussed above). The displayed records may be sorted based on how recently the records were accessed. For example, the most recently accessed records may be at the bottom of the list.

[0046] At 610, a selection of a record is received from the user. The user can select a record by clicking on it. Additionally or alternatively, each record may be displayed as a radio button, and the user selects the record by selecting the corresponding radio button. Additionally or alternatively, the records may be displayed in and selected via a drop-down box.

[0047] In step 612, a form is generated. An example of a form is shown in Figure 5 (discussed above). The form includes GUI components (e.g., text boxes) that correspond to the selected fields (from step 606) in the selected records (from step 610). The GUI components may be populated with the current values ​​of the selected fields in the selected records.

[0048] At 614, an updated value for the selected field in the selected record is received from the user via the GUI component. Specifically, the user can operate the GUI component to input the updated value. This updated value can be stored in the selected field of the selected record.

[0049] In one or more embodiments, it may be determined that two or more fields are frequently updated together. For example, it may be determined that when field X is updated by a user, time field Y is also updated by the user 95% of the time. In such an embodiment, the generated form may have multiple GUI components (e.g., text boxes), one GUI component corresponding to a selected field (e.g., field X) in the selected record, and one or more remaining GUI components corresponding to other fields (e.g., field Y) in the selected record that are likely to be updated along with the selected field. These updated values ​​for the multiple fields may be stored in the selected record.

[0050] Although step 606 only refers to selecting a single field, it may be possible for a user to select multiple fields belonging to the same record type. In such an embodiment, the form in step 612 may include multiple GUI components (e.g., text boxes), each corresponding to one of the selected fields. These updated values ​​for the multiple selected fields may be stored in the selected record.

[0051] Although step 610 only refers to selecting a single record, it may be possible for the user to select multiple records. The selection process may include the user clicking on multiple records of interest from the displayed records. Additionally or alternatively, the records may be grouped / organized into multiple lists, and selecting multiple records may include the user selecting one of the lists.

[0052] FIG. 7 shows an example screen 700 according to one or more embodiments. FIG. 7 may be displayed after a user selects field W (at 606 in FIG. 6). As shown in FIG. 7, multiple record lists are displayed (e.g., record list A 702A, record list B 702B, record list Z 702Z). Each record list 702 contains one or more records of a record type that includes the selected field W. In this example, assume the user selects record list A 702A and has five records in that record list A.

[0053] FIG. 8 shows an exemplary form 802 that may be generated in response to a user selecting record list A 702A. As shown, form 802 identifies one of records 806 from the selected record list (e.g., record list A) and identifies a selected field 808 (e.g., field W). Form 802 further includes a GUI component 816 (e.g., a text box) that corresponds to the selected field in the identified record of the record list. When form 802 is initially displayed, GUI component 816 may be populated with the current value in the selected field of the identified record. In one or more embodiments, GUI component 816 may be pre-filled by the system with an expected update value (discussed below). If the expected update value is incorrect, the user can select button 818. The user can enter an update value by manipulating GUI component 816. In response to selecting a “Save and Next” button 814, the update value provided by the user can be saved in the selected field of the identified record, and a new form is generated and displayed. This new form is essentially the same as form 802, except that the new form identifies the next record in the list of records, and GUI components (e.g., text boxes) in the new form correspond to selected fields in said next record. Each time the "Save and Next" button is selected, a new form is generated to update the selected fields of the next record until the last record in the selected list of records is reached. This is sometimes referred to as a bulk-update. A counter 899 may be displayed at the top of the form to indicate progress in updating the records in the list of records.

[0054] Similar to the "Save and Next" button 814, the "Skip" button 810 also generates a new form for the next record in the list of records. However, selecting the "Skip" button 810 does not save the updated values ​​provided by the user (via GUI component 816) to the selected fields of the current record. Selecting the "Close" button 812 terminates the bulk update.

[0055] Next, we will discuss in more detail the user's pre-filling of GUI component 516 or GUI component 816 with expected updated values ​​based on the stored, previously entered values ​​of the first record. In element 516 or 816, the user can enter a keyword (KW). For example, each time the seller 122 updates field 516 or 816, the seller 122 can uniformly begin their entry by entering known parameters such as the current date, time, day of the week, etc., or they can append their entry to a set of previous dated entries.

[0056] Previously entered entries can be analyzed through machine learning pattern detection analysis to determine if commonly detected parameters such as date, time, day of the week, etc. have been entered or if an append to a previous entry has occurred.

[0057] This specification describes modules used to generate such decisions. In one embodiment, such modules may be a neural network with hidden layers and backpropagation, as shown in FIG. 9A. The input in this case is one or more keywords typed by the user in response to a prompt at 516 or 816, with each saved entry of the user at 516 or 816 forming a distinct set of inputs. The neural network can be used as a machine learning classifier on these inputs to designate one or more potential categories of detected parameters, such as date, time, day of the week, append, or none of the above. Using such a classification technique, it may be possible to create a system of weighted nodes that can be used to provide a reliable prediction of the parameter category to which the user's input belongs. This specification describes different components of the neural network model shown in FIG. 9A, according to some embodiments. The input layer 902a includes nodes 1-i, which represent inputs to the model. Each of these nodes corresponds to a different aspect of the input string. In particular, a user's input string, such as at 816, is first tokenized into words, and the tokenized words are stemmed. Training data may be used (if the category is known), in which complete sentence descriptions of products may be transformed. Such transformation may involve tokenizing each word in the sentence description into a known category, creating word stems, etc. After sufficient training data has been used, there may be a collective library of word stems, some of which are associated with only one category, some of which are associated with multiple categories, etc., so that when the input string in 516 or 816 is parsed separately, one input node may correspond to each word, and these nodes can be compared to the library of word stems associated with each category.

[0058] For example, the word stem "Jun" or "06 / " might be found in a library of word stem sequences associated with the category "month." Thus, if a user inputs "June 10, 2020" as part of input string 816, node 1 of input layer 902a could represent the word stem "Jun" (month), node 2 could represent "10" (day), and node 3 could represent "2020" (year). These nodes can then be compared to word stems from a training library (called a "bag of words"); nodes 2-3 can be assigned a value of 0 if they do not match any word stem in the bag of words, and node 1 can be assigned a value of 1 if it matches a stem in the bag of words (in this example, it matches "Jun" from above). In practice, the input is parsed and correlated with a series of 0s and 1s, where 1s correspond to words found in the bag of words.

[0059] Through iterative rounds as the neural network is trained with training data, each stem has a different weight w associated with it that advances to the next layer 904a and ultimately to the output layer 906a. ij This is because some words in the bag of words may have associations with particular categories and may be more important than others. For example, the word "twenty" may be considered less important than a word stem such as "2020," which clearly indicates the year of the date. The output layer 906a may, as an example, include five nodes, nodes 1, 2, 3, 4, and 5, representing five categories (e.g., date, time, day of the week, append to previous entry, or catchall for none of the above).

[0060] The inputs and weights from each node to other nodes (w shown in Figure 9A) ij), the results of the output layer are aggregated, and the node (1-5) in the output layer with the largest result is output as the result of the predictive analysis. In this case, the weight from the input layer node to output layer node 1 may carry a larger weight than the input layer node to output layer nodes 2-5 (assuming output layer node 1 represents a date) because "Jun" may have a particular association with months and "2020" may have a clear association with years.

[0061] When traversing from the input layer 902a to the output layer 906a, there may be several hidden layers 904a. The number of hidden layers 904a may be preset to one, or there may be multiple layers. When the number of hidden layers 904a is one (as shown in FIG. 9A), the number of neurons in the hidden layer can be calculated as the average of the number of neurons in the input layer and the output layer. This is derived from an experience-based rule of thumb in facilitating the calculation of weights across layers. A further rule of thumb states that in one embodiment to prevent overfitting, the number of neurons in the input layer 902a should be N i and the number of neurons in the output layer is N o and the number of samples in the training dataset of all word stems associated with a category is N s If , the number of neurons in one hidden layer is N h teeth,

number

[0062] Based on the weights from each node in the input layer 902a to the hidden layer 904a shown in Figure 9A, there may be a sigmoid transfer function when going from the input layer 902a to the hidden layer 904a. Initially, the weights w i,jcan be initialized to a random value between 0 and 1. Word stems of input nodes that correspond to word stems in the bag of words can then be propagated along these weights (forward propagation), and hidden layer 904a forms the initial outputs for neurons in input layer 902a. For example, the input given as "purple" to neuron 1 in input layer 902a in the example above would be multiplied by 0 if it did not correspond to a word stem in the bag of words.

[0063] In contrast, neuron 1 ("June") has a 1j weights w 11 and w 12 etc., and in the same way these hidden layer nodes are summed to form the output for hidden layer 904A (e.g., node 1 in the hidden layer in the example above is multiplied by w 11, +w 21 +w 31 +w 41 ) Node 1 in hidden layer 904a can then take this net value and propagate this activation value to see what the neuron output forward to the output layer actually is. At each output layer (hidden layer 904a for input layer 902a and output layer 906a for hidden layer 904a), a sigmoid activation function

number

number

[0064] In the above example, the output from input layer 902a to neuron 1 in hidden layer 904a is input as an activation value and passed to one of the transfer functions mentioned above in hidden layer 904a, and the output forms the value of neuron 1 in hidden layer 904a and is passed forward as an input to output layer 906a, where it is multiplied by the respective weights for neurons 1 and 2 in the output layer. In this way, full forward propagation of input nodes 1-I in input layer 902a can be achieved to output layer 906a.

[0065] Then, to perform backpropagation, the error between the expected output and the forward-propagated output from the network is calculated. In training a neural network, k-fold cross validation may be used, especially when the dataset is small. In k-fold cross validation, for example, there may be an aggregated set of all sentence descriptions entered by a user that are known to be associated with date (category 1), time (category 2), day of the week (category 3), append (category 4), or neither (category 5), with each group having a different associated word stem, including all of the components described above. This set of sentence descriptions can be shuffled and divided into k groups (e.g., 5 groups if k is 5, each holding a specific number of results (category 1 / category 2) and corresponding associated word stems). Then, for each unique group, that group is held out as a test dataset, and the remaining groups of aggregated sentence descriptions can be used to train a classifier.

[0066] Finally, based on the training, the accuracy rate for the test group can be evaluated. One group can be kept for testing, and the other group can be used to train the model. In this method, the error is calculated between the expected output of 1,0 described as such and the output actually forward-propagated by the network (initially with the random weights assigned as described above).

[0067] To propagate the error, the error signal that propagates back through the network is given by error=(expected-output)*transfer_derivative(output), where transfer_derivative is the derivative of the transfer function used (sigmoid, hyperbolic, or SmoothReLU).

[0068] An error signal for the neurons in the hidden layer 904a is then calculated as the weighted error of each neuron in the output layer according to the weights from the output layer to the neurons in the hidden layer 904a. Similarly, the error signal from the hidden layer is then propagated back to the input layer 902a. Once the error is calculated for each neuron in the network via the described backpropagation method, the error is used to update the weight according to the formula new_weight=old_weight+learning_rate*error*input, where the old_weight variable is the previous given weight in the model, the learning_rate variable is a value between 0 and 1 that specifies how much the old weight should be changed to correct for the error, the error variable is the error calculated by the backpropagation procedure, and the input variable is the value of the input that caused the error.

[0069] Over time, this model can be developed to form robust predictive analytics. For a given input, there are likely several potential output categories, and output layer 906a may consist of dozens or even hundreds of nodes. Each output node at the end has a score between 0 and 1. The output node with the most nodes is considered to be the most likely category of product with which the user's input (e.g., in field 516 or 816) may be associated, and such elements can be automatically pre-filled into the form (e.g., date, time, day of the week may be filled in, or previous entries can be left as they are as new information is continually appended). Thus, the second-highest score would indicate the second-most likely category of product associated with the user's input, and so on. Herein, if two nodes exceed a certain threshold, it may mean that the tokenization in 816 indicates that both elements are present. In this manner, the threshold in output layer 906a can be used to determine which elements should be pre-filled into form 500 or 802 for display.

[0070] Once these categories are displayed, the user can verify or invalidate the results through feedback from the GUI; if the pre-filled text is incorrect, the user can click 518 or 818. If the user does not click this button, a value of "1" is entered into the output layer, and the other categories become "0", and this result is back-propagated as described above to adjust the weights in the hidden and input layers to make the model more robust for future processing.

[0071] Scores are determined for the fields as discussed above in step 602 of Figure 6. In one or more embodiments, machine learning analysis and weighted machine learning analysis may be used to determine the scores and therefore the fields most likely to be accessed by the user.

[0072] First, a machine learning analysis can be performed using a support vector machine (SVM). In this embodiment, when determining a score for a record, data from related factors is taken into account along with the frequency of access. For example, if a user 202 always has different records or fields that he or she accesses depending on the day (Monday - financial, Tuesday - sales report, etc., to update the values ​​of fields in these records), simply determining the most frequently accessed records or fields will not help the user overcome the obstacle of searching for each of these records. Other patterns may exist, such as a user only accessing certain records after 9 p.m. (e.g., nighttime sales figures to update), or a user may access certain records or fields when the weather is particularly rainy or the user is traveling (e.g., travel compensation, etc., compensation related to weather-related damages, etc.). A hyperplane can be created for each SVM protocol to take these patterns into account and recognize the impact they may have on the scoring of the user's overall "affinity" for accessing them.

[0073] That is, all of these patterns can result in a binary result, and the user either accessed or did not access the record for each of these patterns (the user accessed the record or field because of the weather, or did not access it because of the weather). As a result, a record or field can be designated as associated with a feature based on the frequency of access of the record or field with or without a particular noted associated feature (weather, time of day, weather, movement, etc.) at a respective threshold (e.g., 35% or more, or any other predetermined value determined). Conversely, if the frequency of access of the record or field with or without a particular noted associated feature is below the respective threshold, the record or field can be designated as not associated with the associated feature. Furthermore, the threshold for each associated feature can be set and fine-tuned over time to reflect or not reflect association. In this way, for each associated feature, there is a binary designation of associated or not, and then a hyperplane is found using the SVM method to separate these points.

[0074] To determine which features should be weighted more heavily in finding such a hyperplane, a technique called feature-weighted SVM is used, as shown in Figure 9B. In this figure, a random forest bagged classifier consisting of an ensemble of classification trees (CTs) is used. Each tree can be constructed using a different bootstrap dataset with a randomly chosen sample of records (from the pool of all records), and each node can be split using the best randomly selected associated features. These two types of randomness help determine the most important features to prevent model overfitting and noise. First, from the original dataset, a random number n features are selected from all associated features at the first node (e.g., 904b or 912b). Then, for the kth feature, where k = 1, 2, .... n, the best split s is determined. k is used. The data is then split at the node using the best split s among the n best splits. The previous three steps are then repeated at every node. This results in a forest of trees, tree 1 through tree Z, as shown in FIG. 9B. To determine which features had the most influence on the splitting of all trees in the forest, the Gini index method may be used to accumulate the Gini reduction at every split in the forest due to a given feature.

[0075] To calculate the Gini decline, the formula is

number

[0076] This field can be included in the top N fields displayed to the user (as shown in and discussed above with reference to FIG. 3). An advantage of performing a Gini analysis is that it helps weight the features taken into account by the SVM. The effect can be seen in FIGS. 10A and 10B. As can be seen in FIG. 10A, by weighting the features, the SVM also performs better in terms of outlier sensitivity. Cluster 1006a is more evenly divided by the feature weighting using line 1004a, as opposed to the original line 1002a, which is drawn to the right by the outlier on the right side of the line.

[0077] Furthermore, as shown in FIG. 10B , the Gini index clearly indicates that feature 3 is several orders of magnitude more important than the other features. If this is time of day versus travel versus day of week versus weather, and one of them has clear importance, it is important to evaluate the frequency of access by user 202 in relation to that particular associated feature to determine which records or fields the user is likely to access according to their corresponding importance. As a result, the feature weighting from the Gini index and machine learning analysis applied to the random classifier model act as a robust predictor of what the user is likely to access, while taking into account associated variables that may not normally correlate with having importance. As a result, a strong level of prediction can be made, and the corresponding record or field, or a predetermined number of records or fields (per their Gini index) can be included in the top N fields displayed to the user (as shown in FIG. 3 and discussed above with reference to FIG. 3).

[0078] It should be understood that the Detailed Description section, and not the other sections, is intended to be used to interpret the claims, which may represent one or more example embodiments, but not all, contemplated by the inventors, and are therefore not intended to limit the scope of the disclosure or the appended claims in any way.

[0079] While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible and are within the scope and spirit of the present disclosure. For example, without limiting the generality of this paragraph, the embodiments are not limited to the software, hardware, firmware, and / or entities illustrated in the figures and / or described herein. Moreover, the embodiments (whether or not explicitly described herein) have significant utility for fields and applications beyond the examples described herein.

[0080] Embodiments are described herein with the help of functional building blocks that illustrate implementations of specified functions and relationships thereof. The boundaries of these functional building blocks are arbitrarily defined herein for convenience of description. Alternative boundaries may be defined so long as the specified functions and relationships (or their equivalents) are appropriately performed. Furthermore, alternative embodiments may implement functional blocks, steps, operations, methods, etc. using an ordering different from that described herein.

[0081] References herein to “one embodiment,” “one embodiment,” “one exemplary embodiment,” or similar phrases indicate that the described embodiment may include a particular feature, structure, or characteristic, but not all embodiments necessarily include that particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with one embodiment, incorporating such feature, structure, or characteristic in other embodiments, whether or not explicitly mentioned or described herein, is within the knowledge of one of ordinary skill in the relevant art. Furthermore, some embodiments may be described using the expressions “coupled” and “connected,” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms “connected” and / or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term “coupled” can also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0082] The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. 1. A computer-implemented method comprising: causing, by at least one processor, a plurality of fields to be displayed based on a plurality of scores for the plurality of fields; receiving, by the at least one processor, a selection of a first field of the plurality of fields; causing, by the at least one processor and in response to the selection of the first field, a display of a plurality of records of a record type that includes the first field; receiving, by the at least one processor, a selection of a first record of the plurality of records; generating, by the at least one processor and based on the selection of the first record, a first form including a first graphical user interface (GUI) component for the first field in the first record; receiving, by the at least one processor and via the first GUI component, a first updated value for the first field in the first record; storing, by the at least one processor, the first updated value in the first field within the first record; A method comprising:

2. entering an existing value of the first field in the first record into the first GUI component prior to receiving the first updated value; The method of claim 1 further comprising:

3. determining that a second field is frequently updated after the first field; the first form including a second GUI component for the second field in response to determining that the second field is frequently updated after the first field; receiving, via the second GUI component, a second updated value for the second field in the first record; storing the second updated value in the second field in the first record; The method of claim 1 further comprising:

4. 2. The method of claim 1 , wherein receiving the selection of the first record comprises receiving a selection of a subset of the plurality of records, the subset of the plurality of records comprising the first record and a second record.

5. generating a second form including a second graphical user interface (GUI) component for the first field in the second record; displaying the second form in response to selection of a button on the first form; receiving, via the second GUI component, a second updated value for the first field in the second record; storing the second updated value in the first field in the second record; The method of claim 4 further comprising:

6. 2. The method of claim 1, wherein the first field is associated with a score from the plurality of scores, the score associated with the first field is incremented in response to an update to the first field, and the score decays over time.

7. The method of claim 1 , wherein the plurality of scores is determined using a random forest approach.

8. 1. A system comprising: Memory and at least one processor coupled to the memory; displaying a plurality of fields based on a plurality of scores for said plurality of fields; receiving a selection of a first field of the plurality of fields; responsive to said selection of said first field, displaying a plurality of records of a record type including said first field; receiving a selection of a first record of the plurality of records; generating a first form including a first graphical user interface (GUI) component for the first field in the first record based on the selection of the first record; receiving, via the first GUI component, a first updated value for the first field in the first record; storing the first updated value in the first field in the first record; at least one processor configured to: A system including:

9. The at least one processor further comprises: Entering the existing value of the first field in the first record into the first GUI component before receiving the first updated value. The system of claim 8 , configured to:

10. The at least one processor further comprises: determining that a second field is frequently updated after the first field; the first form includes a second GUI component for the second field in response to determining that the second field is frequently updated after the first field; receiving, via the second GUI component, a second updated value for the second field in the first record; storing the second updated value in the second field in the first record; The system of claim 8 , configured to:

11. 9. The system of claim 8, wherein receiving the selection of the first record comprises receiving a selection of a subset of the plurality of records, the subset of the plurality of records comprising the first record and a second record.

12. The at least one processor further comprises: generating a second form including a second graphical user interface (GUI) component for the first field in the second record; displaying the second form after the first form in response to selection of a button on the first form; receiving, via the second GUI component, a second updated value for the first field in the second record; storing the second updated value in the first field in the second record; The system of claim 11 configured to:

13. 9. The system of claim 8, wherein the first field is associated with a score from the plurality of scores, the score associated with the first field is incremented in response to an update to the first field, and the score decays over time.

14. The system of claim 8 , wherein the plurality of scores is determined using a random forest approach.

15. A non-transitory computer readable medium (CRM) having stored thereon instructions that, when executed by at least one computing device, cause the at least one computing device to perform operations, the operations including: displaying a plurality of fields based on a plurality of scores for the plurality of fields; receiving a selection of a first field of the plurality of fields; responsive to said selection of said first field, displaying a plurality of records of a record type including said first field; receiving a selection of a first record of the plurality of records; generating a first form including a first graphical user interface (GUI) component for the first field in the first record based on the selection of the first record; receiving, via the first GUI component, a first updated value for the first field in the first record; storing the first updated value in the first field within the first record; Non-transitory CRM, including:

16. The operation is Entering an existing value of the first field in the first record into the first GUI component before receiving the first updated value.

16. The non-transitory CRM of claim 15, further comprising:

17. The operation is determining that a second field is frequently updated after the first field; the first form includes a second GUI component for the second field in response to determining that the second field is frequently updated after the first field; and receiving, via the second GUI component, a second updated value for the second field in the first record; storing the second updated value in the second field within the first record; 16. The non-transitory CRM of claim 15, further comprising:

18. 16. The non-transitory CRM of claim 15, wherein receiving the selection of the first record includes receiving a selection of a subset of the plurality of records, the subset of the plurality of records including the first record and a second record.

19. The operation is generating a second form including a second graphical user interface (GUI) component for the first field in the second record; displaying the second form in response to selection of a button on the first form; receiving, via the second GUI component, a second updated value for the first field in the second record; storing the second updated value in the first field in the second record; 20. The non-transient CRM of claim 18, further comprising:

20. 16. The non-transitory CRM of claim 15, wherein the first field is associated with a score from the plurality of scores, the score associated with the first field is incremented in response to an update to the first field, and the score decays over time.

Images