Xeelo - configuration - suggested tips

Xeelo Knowledge Base
, ,
1

Suggested tips

Fields addition

  • Configure fields in english (system language) and according to a client native language, translate it to that language right away (it will save you a lot of time in the end)
  • Properties / Visibility
    • When it make sense, set a „History“ attribute to field (e.g. “Customer name”)
  • Set Properties / Search & sort (only object)
    • On Grid
    • Custom filter
  • Properties / Template
    • When it make sense, set a “hint” and translate it right away
    • Mostly where user would not understand the purpose of the field and would be great to display hint for him/her
  • Properties / Index (only object)
    • Set where it makes sense. On fields which will be most likely used for searching (it will help with a performance)
  • Do not forget UNIQUE attribute (it is crucial for imports)
  • For combo-boxes set „Show link“ if it makes sense – e.g. combo-box with list of vendors (object in Xeelo). It’s comfortable to display selected “Vendor” with using “Link” icon on combo-box
  • Translate tabs and sections right away

Field layout on form

  • Rather than user using scrolling all the time, it is better to assign fields to tabs. The most important fields set on the first tab (aligned to the left), so user can see it right away.
  • Very simple objects can have tabs aligned to the right and the whole width can be used then

System fields

  • !!! Calculation order (object, sub-grid) – DO NOT FORGET. Set it everytime you add a new calculation.
    • DO NOT FORGET to assign line with a SubGrid to calculation order on object!
    • it is good to add fields (sort them) how they are gonna be calculated (order of calculation)
  • Use „comments“ on fields, at least a purpose of a field, how the a value is filled out/calculated (by user, import, export, Obejct action) or explain a calculation that is set on the field
  • Fields that are calculated just by server calculations set as „always hidden“
  • It is not bad to put fields with similar purpose into one section. E.g. all the fields that are exported to certain object and calculated on that export, have them assigned to one particular section called “Export to object A”
  • If you have a lot of system fields, you can create another system tabs and name the e.g. “System - 1”, “System - 2” etc. You can also set fields to these system tabs according to when they should be calculated (e.g. one filed in “System - 1” must be calculated before another field in “System - 2”

Templates

  • It is good to think about if you need more than one template on object. Mostly you will use one default template but sometimes it is better to have multiple templates. It depends on a case.
  • On SubGrid, sometimes it is better to have more templates and sometimes it is better to create new SubGrids.

SubGrid

  • Think about possibility of “create copy” and “delete” for SubGrid
  • Do not forget to set „Searching & „Paging“ when necessary (multiple records in SG)
  • Default sorting is quite good but keep in mind that system must sort it according to a field you set within all the records in the SG
  • When it make sense, set „Quick edit“ a „Multi select“
  • You should also keep in mind, that when you add a field in SG, attribute “Search” is set by default (unlike on object). But you do not want it on system fields, so do not forget to uncheck this attribute.
  • Do not forget about UNIQUE value on the SG. In most cases you will needed but sometimes you won’t.

OnGrid

  • When it makes sense, disable „label“ on fields. (Properties / On Grid)
    • E.g. fields like “Currency” or a field with “Autonumber” value.
  • It is not good to set combo-boxes on grid. If you have free field slots, create a text-box, set a calculation to it (that will take the value from the combo) and assign it on grid. It is better for performance.
  • Think about possibility to set attribute “Tag” on text-boxes. Tag will automatically create a filter in the object overview. Keep in mind how many filters it will make (it is for example good to set it on years - system will display filter e.g. “2018”, “2019” …)

Memo vs. DescMemo (performance)

  • When a Memo field is not editable in particular WF steps, it is better for performance to create a DescMemo in which you will display value from Memo field and this Memo field will be hidden.

WF

  • Make sure you set „Export fail“ a „Workflow fail“ role and status (make an Admin role for that), when export fails or request is not assigned to any user.
    • It is good to create WF actions from these statuses to all WF statuses, so Admin is able to move it to any step. Think about assigning a notification to these states. It is also possible to assign special permissions in Admin, in object in tab “Admin”. You are then able to move a request by “Actions / Change WF”
  • If it is needed, then set Recall status (possibility of requestor to recall request from any state (not completed) that is not assigned to him/her).
  • WF step
    • Where it make sense, set „Action on Save“, when a role is not changed when moving from one step to another. If there is a possibility that a user will be assigned in one step and in a subsequent one, set “Open only” (when it is needed to fill in something new) or “Open and show WF actions” (when it is not needed to fill in something new)
    • Be aware of „All role approval“ – this is essential when request is assigned to more than one user and you need to ensure that all these assigned users must approve it. If just one out of all assigned users is needed for an approval then do not set it.
    • set WF access
  • WF actions
    • Set „OnGrid“ for actions that lead forward and set „Special“ and „Comment“ for actions that lead backwards
    • When there is an action that leads to “Cancelled” state, it is not necessary to set „Comment“, but keep „Special“ set.
    • For offline actions, do not forget to set “Offline” attribute
    • Translate WF actions!

Calculations on object vs. on WF

  • If you know that a value of a field is going to be calculated just once, or it is needed to calculate it just once, it is better to set this calculation on WF step, on the first WF step, e.g. “Saved”. Like “RequestorID”, “RequestID” or “CreatedDate”.
    • If you have just on WF step on a WF, you can set it on object.
  • When you set WF calculations, make sure you set the right order of these calculations and think about if there is a need to annul values calculated with these calculations in following steps.
  • Think about order of actions when request is „refreshed“ (https://forum.xeelo.com/t/what-is-executed-when-request-is-actioned/53)
  • Think about a case when you need to calculate fields on just certain WF steps. Of course you can set it on WF but sometimes it is better to create an Export (type “CSV”) and set just calculations on it. Then create an object action “Export force” and assign this export to it. Finally you can set this OA with export on WF steps where you need it. This will calculate all calculations set on that export and it will initiate these calculations when request gets into particular WF step, when request in that step is saved (user saves it, or import with refresh is done) and when request is leaving that step.
    • This can have a very good impact on performance, because when you set calculations on object and they just need to be calculated on two steps out of 10, they will be uselessly calculated on the other WF steps when it is not needed.

20
201358×774 267 KB

References and Lookups

  • Naming convention
    • It is good to choose a good naming convention for references and lookups. e.g.: „Vendor – Currency“
  • Set “Relation” on references when it make sense. With this attribute you will set relations on objects.
  • Tip – unique value on a referenci is „Value“
    • On Lookupu, it is „Source“ + „filter“

Export & Import

  • Export - Naming convention
    • It is good to name exports with from which object export is initiated to which object it goes. E.g.: „Purchase order -> Vendor“, eventually you can also write what is exported or that with that export you create a new request, etc.
  • Import
    • It is better to have minimum imports, and on these imports set import sections according to what is imported, e.g.: you have one import “Vendor” and import sections:
      • Request (new)
      • SG – Bank accounts
      • SG – Contacts
      • ….
    • Naming convention – name Import according to an object, and detailed name set for the import section
  • If you need „Update“ on object just for Export / Import, it is good to set a condition to this update, which will never be met and because of that no one will ever have that update action available as a user.

Calculations assigned on printouts, notifications, exports

  • If you need to calculate something just for a printout, notification or export, it is better to set it right on that output and not on object. You still need a field for that.
  • If you do not need a field or you woul like to save a few slots, you can set a temporary calculation and assign it on output (printout, notification, export).
6 Likes
2

Excellent article, thank you, Peťo.
Everyone should print this text and put it on desk.
Read it before start of new project and read it again at the end for check if everything is done as you described.

3 Likes