Jump to content

Curious how to create a loop


Lisa M.

This topic is 510 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hi All:

 

So, I'm back in FileMaker 12 once again to make yet another database and I think I've gotten my wires crossed a bit.  What I'd like to do is create a troubleshooting system as follows:

  • First select a problem type (iPhone/iPad Issues) and hit next
  • select a subtype (Accessibility).  If the problem isn't listed in the first screen of radio buttons, show a "It's Something Else" radio button to show even more radio buttons with first level choices (if there truly is that many choices in the first-level problems table).
  • loop through the first two until the most specific problem definition possible has been arrived at (Example: iPhone/iPad Problem > Settings > Accessibility > Vision > VoiceOver > Speech > Customer wants to change the voice used by VoiceOver)
  • display a brief text explanation of where we are thus far, and offer possible solutions based on the previous selections that are now known about the problem (example: Changing the voice used by VooiceOver allows one more level of customization to your iPhone or iPad, I'll walk you through how to do it)
  • once a solution is clicked display information about the solution in a setp-by-step wizard fashion (example: "go to your home screen then open settings." or "Ask Siri to Open VoiceOver Settings.") then when you hit "next" based on the route the customer took either explain where the voice selection is one screen or so at a time. or if they're already there just explain where that setting is) once you're all out of steps ask if that fixed the problem, if yes start over, if no, show more possible solutions until we run out of possible solutions to try.
  • if at any time we need to go back, know where we came from thus clicking "Back" will always bring us back to the previous screen.
  • if the user clicks "Start Over" then clear out all we know about the problem and start "from the top"

 

Wht My Databse Looks Like Now:

  • Global Table
    • G_ProblemTypeID
    • G_NextProblemTypeID
    • G_PrevProblemTypeID
  • ProblemTypeTable (Major and Minor Problem Types) (Major Problem Types are the top-level problems (like iPhone/iPad Issue, email Issue, etc.) while "Minor Problem types" are the more granular issues)
    • _PK_ProblemTypeID (AutoEnter Serial Prohibit Modification)
    • ProblemTypeDesc
    • ProblemText
  • LocalActions (These are the prompts for the agent on the receiving side of the call or chat)
    • _PK_LocalActionID
    • __FK_RemoteActionID (one local action can be called upon by many different remote Actions)
    • LocalAction
  • RemoteActions (These are the steps the user (the person initiating the interaction takes)
    • _PK_RemoteActionID
    • RemotteActionName
    • ActionText

 

What's gone wrong:

 

I seem to have forgotten how to do the whole "one problem can have many sub-problems" relationship without creating  totally new table else I'd be making tables for days depending on how deep I wanted to go with problems, steps to solve them, etc.

 

Basically my objective is to make everything I know into a "Conversational" troubleshooter then give it to my friends who also do "family tech support" thus guiding them to the right solution regardless of how broad the person needing help's initial definition of the problem is (so long as the description isn't "it's broken" or "it's not working right") and guiding the person needing help on how to perform the actions needed to accomplish it while keeping both sides of the call "on track" resolving one problem at a time and ensuring that no step or process is left behind.  The prompts are not meant to be a "read this exactly as it's written" type of affair but more so "this is how I would word it, feel free to make it your own" thus the person giving help doesn't sound like one of those IVR automated troubleshooters like you'd typically run into when calling your ISP.  At some point I'd like to even include pictures on each step thus the person doing the troubleshooting can see what the person requesting help's screen should look like.

 

Again maybe my brain is fried, maybe I need to go back to "FileMaker Essentials class", maybe my dreams are just too ambitious, but I'm trying to help my friends out here considering it's the holiday season and goodness only knows what questions the family might have about their "shiny new toys"...

 

Anyhow, I'm hoping that someone has a few ideas to help get me back on the right track in building this thing.

Link to comment
Share on other sites

1 hour ago, Carly F. said:

how to do the whole "one problem can have many sub-problems" relationship

In the situation you describe, where there can be many levels of hierarchy and - especially - not all branches of the hierarchy tree have the same number of levels, I would use a single Problems table with two self-join relationships:

ParentProblem -< Problems -< SubProblems

Here you work from a layout based on the Problems TO and you show the sub-problems in a portal to SubProblems. And you use the Go to Related Record script step to move up/down the hierarchy tree.

Note that there are no global fields here (at least not for the basics); each Problem has a unique ProblemID and also a ParentID field to connect it to its parent.

Note also that we are assuming each problem has only one parent problem.

 

Edited by comment
  • Thanks 1
Link to comment
Share on other sites

41 minutes ago, comment said:

In the situation you describe, where there can be many levels of hierarchy and - especially - not all branches of the hierarchy tree have the same number of levels, I would use a single Problems table with two self-join relationships:

ParentProblem -< Problems -< SubProblems

Here you work from a layout based on the Problems TO and you show the sub-problems in a portal to SubProblems. And you use the Go to Related Record script step to move up/down the hierarchy tree.

Note that there are no global fields here (at least not for the basics); each Problem has a unique ProblemID and also a ParentID field to connect it to its parent.

Note also that we are assuming each problem has only one parent problem.

 

Thanks 🙂 I'll give that a shot as soon as I get to it.  Right now I'm kind of playing "Let's see how this works... in a lab with Mac OS 9 right now so fun times!

Link to comment
Share on other sites

This topic is 510 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.